RE: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
parsers need to canonicalize maps to any depth in order to detect duplicates. This is complex by any definition of the word. It isn't complex in terms of computational efficiency ... you can canonicalize in O(N log N) and do it while reading. And the consequence of not using structure-equality in duplicate detection is complex. I think CBOR should be clear about how it handles sharing and equality. agree. Larry -- http://larry.masinter.net (obscure footnote: Serializing structures with duplicate pointers is fun, you need some notation to signify back pointers and to drop anchors. Using hash tables and canonical values was part of the circlprint/hprint http://pdp-10.trailing-edge.com/decuslib20-01/01/decus/20-0004/21lisp.tty.html implementation.)
RE: Last Call: draft-bormann-cbor-04.txt (Concise Binary Object Representation (CBOR)) to Proposed Standard
BCP 70 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols attempted to outline some of the design considerations for data representation using XML. In 2003, it represented the consensus and also the disagreements about what was best current practice at the time. Section 3 of BCP 70, Alternatives, lists some of the alternatives and provides a comparison. I think what might be missing is an update to BCP 70 or a companion which more explicitly compares XML, JSON, CBOR and other alternatives in use in IETF protocols. If you're interested in this work, perhaps you might review BCP 70 and suggest updates. Larry -- http://larry.masinter.net
RE: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Not at all. There is a huge difference between ask participants in a discussion what they think and a consensus call. I've frequently seen postings that talk about the consensus of a Bar BoF, and never seen any objection to that terminology. Consensus is always qualified by the scope of the participants, and we all know how to tell the difference between consensus of the IETF, consensus of the room, consensus of the working group, and consensus of the participants in the mailing list X. I think the process discussion is a distraction from working on the actual issues, and wish it would stop. Larry -- http://larry.masinter.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
RFC 3986 contains a (brief) description of security considerations for agents that produce or receive and interpret URIs. I would expect this document to at the very least reference those security considerations more explicitly, and at best to analyze how they apply in particular to URIs used within SNMP. It's not clear whether it makes sense for SNMP URIs to contain, for example, 'data:' URIs or 'urn:' or any of a number of schemes, and I would expect some discussion about the applicability of URIs within a SNMP context. URIs are defined as a sequence of characters, not a sequence of octets. The mapping should be explicit (e.g., 'use US-ASCII') and not implicit. In practice, many systems allow and produce IRIs (RFC 3987) and not URIs, to allow for accents and non-roman scripts. I wonder if it would be more appropriate to define the MIB value as an IRI encoded in UTF-8, for example. Larry -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 3:02 PM To: IETF-Announce Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Uniform Resource Identifier (URI) MIB ' draft-mcwalter-uri-mib-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-mcwalter-uri-mib-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=15468rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The telnet URI Scheme' to Proposed Standard
I think it would be much more useful if we could update the document sufficiently to consider the telnet URI scheme for Draft Standard or Full Standard. The protocol itself meets the qualifications for a full Standard document; it is widely deployed with multiple independent implementations and has been quite stable for a long time. I think the document itself needs a better discussion of the limited use, security risks, and implementation methods for the user/password fields in a telnet URI, however. Larry -- http://larry.masinter.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'The wais URI Scheme' to Historic
I previously sent my comments to the IESG, but I was asked to re-raise the issue on the IETF mailing list because ... The IESG at this point seems to want public guidance on a document by document basis... on the topic of how to move old documents or protocols to Historic status. In this case, it is the raft of URI schemes currently only documented in RFC 1738. So, to recap: I think it is good to update the URI scheme documents that are in widespread, current and growing use: ftp, file, telnet to move these beyond their Proposed Standard status, update the descriptions, and bring the results along on standards track, by insuring that the documents are consistent with widespread interest. I think it is a bad idea to issue new documents for URI schemes merely to move those schemes to Historic status, wais, prospero, and even gopher. I include gopher even though there may be active or even new gopher client implementations, because I don't believe the gopher protocol or the gopher URI scheme will ever move to full standard. Does anyone see any real need to issue a new document on the gopher URI scheme merely to declare it Historic? Larry -- http://larry.masinter.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Guidelines for the Use of XML in IETF Protocols
Abstract: The eXtensible Markup Language (XML) is a framework for structuring data. While it evolved from SGML -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely- used mechanism for representing structured data. There are a wide variety of Internet protocols; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. Intended Publication Status It is the goal of the authors that this draft (when completed and then approved by the IESG) be published as a Best Current Practice (BCP). Submitted to the Internet Drafts, but available now at http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.txt or http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html with a mailing list [EMAIL PROTECTED] , archive at http://www.imc.org/ietf-xml-use/index.html To subscribe to the mailing list, send a message to [EMAIL PROTECTED] with the single word subscribe in the body of the message. To unsubscribe from the list, use that same address with the single word unsubscribe in the body of the message. Larry -- http://larry.masinter.net
RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational
Shouldn't this be considered as BCP rather than Informational? Formal liaison rules don't substitute well for responsibility and judgment. I would suggest that a set of guidelines for collaboration between IETF and other organizations in general should include an analysis of common failure modes, and encourage the participants to exercise good judgment and oversight so that these don't occur. Think of it like a set of security considerations: analyze the threats and describe how the threats can be mitigated by the form of the liaison relationship. Some examples of common failure modes: *** Someone will misrepresent what's happening in the other group and present their own or their company's point of view as if it were the other group's. This was the example given earlier. The threat is that someone might be given more deference because they are from the ITU. (Note that this isn't so different from the case where a 'representative' from a Major Software vendor stands up and makes statements like 'my company will never implement X'.) *** Someone will game the system, for example, to move forward a technical proposal by telling each group that the other group wants this. So, for example, everyone in the IETF working group tries to help out the ITU by endorsing a proposal because they think the ITU needs it, while everyone in the ITU goes along with it because they think the IETF has already approved it. Meanwhile, nobody really cares or wants this feature. *** People will standards shop: They'll choose one organization or another in response to different requirements on intellectual property claims or assertions, or different requirements for security considerations, or independent interoperable implementations. One group or the other winds up considering technologies or specifications that don't meet their criteria. *** Second-guessing: When turned down by one organization because the proposal is disruptive, inconsistent with that organization's architectural or operational principals, individuals who were frustrated will take the standards proposal to another organization which doesn't have the same design principals or requirements. *** Mutual deadlock: each group is waiting for the other to finish a specification, and there is no way to easily more forward with interlinking specifications. *** Misunderstanding of other group's processes: working groups in one organization avoid doing the coordination with the other organization because of misunderstanding, fear, or deliberate sabotage.
RE: Last Call: IETF and ITU-T Collaboration Guidelines to Informational
*** Someone will game the system, for example, to move forward a technical proposal by telling each group that the other group wants this. One solution to this one might be to close the loop: if a WG is going to act on a claim that the ITU wants such-and-so, then the WG chair checks with the ITU (somehow...). And vice versa, of course. But, as we've established, it's hard to check with the ITU when the liaisons are the ones playing the game; and folks with an agenda are the ones most likely to volunteer for such roles. Just as with protocol security, you can design all of the feedback you want, but there may need to be some kind of intrusion detection to decide if you're being hacked.
RE: RFC2119 Keywords
You'd think that should be the case, and given 2119 it is all that
makes
sense, but there are way too many cases where the subject turns out to
be (explicitly or implicitly) authors of future RFCs.
In RFC 2542 (Terminology and Goals for Internet Fax) I wound up
using a notation {1} {2} {3} to replace MUST/SHOULD/MAY when talking
about what future RFCs should do
{1} there is general agreement that this is a critical
characteristic of any definition of
{2} most believe that this is an important characteristic
of .
{3} there is general belief that this is a useful feature
of ., but that other factors might override;
a definition that does not provide this element is
acceptable.
