Apologies for the lateness of this comment. I only recently found the time to review this draft. Althogh I share Chris Newman's concerns about possible uses of this draft and support the addition of the paragraph he recommends in his DISCUSS vote, I also believe the mechanism defined by this draft will provide very useful functionality in a variety of circumstances and standardization is therefore entirely appropriate. My concerns with this draft revolve around the defined set of message types and the mc field that's part of the vbr-info header field. Possible message type values are "all", "list", or "transaction". The draft also states that the mc value is self-asserted by the sender and is intended to be used for auditing purposes. My first issue with this is that I don't quite get how message type information is supposed to be used during certification validity checking. If successful the DNS lookup produces a list of message types the certifier is willing to vouch for. But how is message supposed to be checked to see if it is of an allowed type? The obvious thing to do is to see if the mc field value in the message is on the list, and the example at the end of section 5 implies that you're supposed to do such a check. It isn't stated explicitly as a requirement, however. If this check is supposed to be done, you're using the mc field as a label, not simply for auditing purposes as the draft states. And if such a check isn't performed, I'm not sure I see much point in having message type information as part of this scheme. My second issue with message types is the lack of any discussion about additional possible message type values. Is this initial set of three value are that are allowed now and forever? If so this seems a little shortsighted. If not there needs to be more discussion of the extensibility model. My third issue is while I see how the "all" value makes total sense in a DNS entry, I don't see how it makes sense as an mc value. This also brings up the issue of how you'd compare mc values to the DNS entries. I would think "all" would act as a sort of wildcard and match any other value. Finally, I note that we have already defined something similar to the message type construct: RFC 3458's message-context. While the list of defined values of the two typing mechanisms are quite distinct at present, as are the intended purposes of the field (message-context is intended as an aid to message processing) I could easily see an argument for a mc value of "fax" or "voice" having validiity, and given how message-context is used in practice it would make quite a bit of sense to define a list-message message context value that would closely parallel the "list" mc value. Again, given the differences in intended use of these fields there is not necessarily any conflict between them. That said, it is not exactly unheard of for "scope creep" to occur. If vbr-info becomes popular I can easily see email-based applications using the mc value in exactly the way message-context is currently used, irrespective of what the specifications say. Such a usage overlap could prove somewhat problematic given message-context's present use for things like divvying up mailbox quotas between, say, voice mail and regular email. Mind you, I'm not going to go so far as to say the VBR mechanism should drop the mc field and use message-context instead, but I think the potential overlaps between these two typing mechanisms needs to at least be looked at. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf