|
> > For these reasons, the tagging scheme described in RFC 2868 is > > not suitable for use as a generic grouping mechanism. Where > > a tagging scheme is required for use with arbitrary data types, > > it is RECOMMENDED that: > > > > * A fixed tagging field be used so as to remove potential > > interoperability issues associated with determining whether > > an optional tag is present; > > > > * The design make no assumption about the content of the > > data within tagged attributes." > > Hmm... OK. This sounds an awful lot like making recommendations on > later RADEXT documents. I'm not sure that's useful. Assuming that the first sentence makes sense, the next question that a reader will ask is "What is the alternative?" > The alternative is to interpret this as recommending a new data type: > tagged attributes with a format defined outside of RADEXT. I'm not sure > I like that much better. Given that existing tagged types are not suitable for generic use, there doesn't seem to be an alternative to a new data type. The question is what this document can or should say about that. While the Extended Attributes document is probably the right place to deal with this issue in depth, the question is whether something can be said in the Design Guidelines document, and if so, what. |