attachment
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class="">
<div><br class=""><blockquote type="cite" class=""><div class="">On Jul 18, 2018, at 8:35 AM, Michael Sweet <<a href="mailto:msweet@apple.com" class="">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="caret-color: rgb(0, 0, 0); font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><br class=""></div><div class="">Page 22, Table 3: Should we be defining a new "ippe" key that specifies the version of IPP Everywhere™ supported? Or one that duplicates "ipp-features-supported" since that attribute's value contains arguably valuable values for filtering?</div></div></div></blockquote><div class=""><br class=""></div>Given that we are still on the same major version and the limited space available for TXT record keys, I'd argue that an "ippe" key is not yet necessary (maybe if we ever get to v2).</div><div class=""><br class=""></div><div class="">As for "ipp-features-supported", what features were you thinking of as valuable for filtering?</div></div></div></blockquote><div><br class=""></div><div>Basically sub-filtering at discovery time for a particular generation of IPP Everywhere™.</div><br class=""></div><br class=""></body></html>