Schema languages for XML (Was: Best practice for data encoding?
On Tue, Jun 06, 2006 at 09:50:22AM -0700, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 42 lines which said: At this point XML is not a bad choice for data encoding. +1 The problem in XML is that XML Schema was botched and in particular namespaces and composition are botched. I think this could be fixed, perhaps. There are other schema languages than the bloated W3C Schema. The most common is RelaxNG (http://www.relaxng.org/). In the IETF land, while RFC 3730 and 3981 unfortunately use W3C Schema, RFC 4287 uses RelaxNG. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
Although I'm an IAB member, I'd rather make my one comment on this draft in public. I think it misses one point that should be mentioned. The easiest way to explain it is to suggest new text: 4.4. Avoiding interference between publication streams Although diversity of views and alternative solutions are common and will commonly be published, it would be highly undesirable for documents published in the different streams to interfere actively with each other, for example by specifying incompatible extensions to the same protocol or alternative uses for the same parameter value. For this reason, the procedures adopted for the four streams will include appropriate checks and balances to avoid such interference. Specifically, this will include a procedure (currently documented in [RFC3932]) to avoid Independent Submissions actively interfering with IETF Documents. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On Wed, Jun 07, 2006 at 03:58:15AM +0200, JFC (Jefsey) Morfin [EMAIL PROTECTED] wrote a message of 13 lines which said: - Appendix A - some names seem to be missing. I could quote a small score of them? I do not know if there are written rules about the Acknowledgements or Credits section in a RFC. It seems quite variable between the RFCs. I am mentioned in draft-ietf-ltru-matching-14 for what I regard as a very small contribution and not in RFC 4408 where I feel that my contribution is more substantive. Anyway, these appendices are not normative and are only useful for historical reasons and to brush the ego :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Michael StJohns wrote: ... In the doc It is the responsibility of the IAB to approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor. This is incorrect. Mike, in absolute seriousness, the time to make that comment was in 1999/2000 when the draft that became RFC 2850 was under consideration, because that is the authority for this text. [Truth in advertising: I was the editor of RFC 2850.] It was expanded from earlier text in RFC 1601 (published in 1994): The IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series... which was modified from RFC 1358 (published in 1992): [IAB] responsibilities shall include: ... (2) The editorial management and publication of the Request for Comments (RFC) document series, which constitutes the archival publication series for Internet Standards and related contributions by the Internet research and engineering community. I am very puzzled by how you believe that the RFC Editor can be made answerable to the community otherwise. I would object most strongly to any notion that the RFC Editor's authority should be self-perpetuating. I would also object to erecting a new bureaucracy for community oversight, given that the IAB exists and is put in place by (and can be ejected by) a community process. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF, IAB, RFC-Editor
Ran, RJ Atkinson wrote: On 5 Jun 2006, at 02:54, Brian E Carpenter wrote: Earlier, Ran Atkinson wrote: It has NOT been the case in the past that IETF was the community in control of RFC-Editor. In fact, that would represent a major, and in many people's view highly undesirable, change. Historically, RFC-Editor has served the broader Internet community, including but not limited to the IETF. In fact, the RFC-Editor has existed since the late 1960s, yet the IETF did not even exist until the middle 1980s. Historically, yes. But I think we're discussing the future. Nevertheless, I personally support the existence of an independent submission mechanism, as part of a general pattern of checks and balances. (See below.) However, I'd like to ask for a definition of the broader Internet community. Since about 1995, the Internet has been a public access network, so I could interpret the phrase as referring to several hundred million people at this point. Since the IETF is open to all, I'm puzzled how to draw a line around the broader Internet community that is meaningfully different from the IETF/IRTF/IAB community but less than the entire on-line population. Brian, It is a fair question. Different people might have slightly different formulations, but I don't think that those would be meaningfully different. Here is a starting point for a definition... I think that the broader Internet community at least includes folks around the world who are engaged in (non-IAB, non-IRTF, and non-IETF) Internet research and development or are academics otherwise involved with the Internet (e.g. through educating college students). I wouldn't want to exclude the operational and implementer community either. I think the phrase used in draft-iab-rfc-editor is probably the best short form: the Internet research and engineering community. Note of course that there is no way to list off the names of that community, and any one of them would be a welcome IETF participant. Brian That collective group is not nearly several hundred million people. Further, that group also has a RFC Editor relationship that long predates the existence of IETF/IRTF -- and also has a current active relationship with the RFC-Editor that is separate from the IETF/IRTF. Their needs primarily relate to a substantial and workable mechanism for individual submissions to actually get published in a timely manner. As the IETF has become MUCH more commercially influenced over the past ~10-15 years, the non-product perspectives that such people often bring to the published RFC document series is increasingly important to the overall health of the Internet. IMHO. All, It is not an accident that the criteria for candidates for IAB are different than for IESG. In my experience, and I'm told that this is not a strange perspective, the IAB functions best when IAB has several members who come from the non-commercial RD/Academic communities -- particularly members who are not particularly involved in IETF standards activities. Those folks can bring a fresh, non-commercial perspective to IAB functions, including but not limited to advice to the IETF/IRTF or input to the RFC-Editor function. Historically, such folks have often done so. As an example, Jon Crowcroft did a wonderful job, yet had not been active in IETF prior to his appointment to the IAB. Of course, he was already quite well known for his Internet research before then. For some years, I've been making this same general observation to the Nominating Committee. Yours, Ran [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
At 10:02 07/06/2006, Stephane Bortzmeyer wrote: On Wed, Jun 07, 2006 at 03:58:15AM +0200, JFC (Jefsey) Morfin [EMAIL PROTECTED] wrote a message of 13 lines which said: - Appendix A - some names seem to be missing. I could quote a small score of them? I do not know if there are written rules about the Acknowledgements or Credits section in a RFC. It seems quite variable between the RFCs. I am mentioned in draft-ietf-ltru-matching-14 for what I regard as a very small contribution and not in RFC 4408 where I feel that my contribution is more substantive. Dear Stephane, This may seem trivial, but IMHO quoting every contributor is important for several key reasons. - the IETF is made of paid and free volunteers. The reward of the free participants is their exposure. If we want top quality participants we must acknowledge their contributions. - every contribution can be a key stone in the final construct. That people like Michael Everson, Ned Freed, Lee Gillam, John C. Klensin, Felix Sasaki, Michel Suignard, and Tex Texin are not quotted seems odd. Others like Scott Hollenbeck and Sam Hartman really helped. What about Karen Broome, M.T. Carrasco Benitez, N. Piercei? Inputs or help from Brian Carpenter, Ted Hardie, Dylan N. Pierce are real. - the IPR is to all the co-authors. Every person having contributed a word, a concept, a change, positively or negatively is a co-author. This also has some importance to show the document is not the work of an affinity group (as discussed in RFC 3774) but of a true WG. - I consider BCP 47 went from an initial error to a technical split of the International US Internet from the Multilingual Global Network. We now need to insure interroperability between them two (for example MGN will accept en-EU, IANA not). Afrer the PR-action, this calls for many experts to accept this is a true IETF proposition. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Perhaps I lead a sheltered life, but on two of these points... - Appendix A - some names seem to be missing. I could quote a small score of them? I do not know if there are written rules about the Acknowledgements or Credits section in a RFC. It seems quite variable between the RFCs. I am mentioned in draft-ietf-ltru-matching-14 for what I regard as a very small contribution and not in RFC 4408 where I feel that my contribution is more substantive. Dear Stephane, This may seem trivial, but IMHO quoting every contributor is important for several key reasons. - the IETF is made of paid and free volunteers. The reward of the free participants is their exposure. If we want top quality participants we must acknowledge their contributions. This is a real concern (I am a working group draft editor for a draft where probably 30 percent of the e-mail I've received on the draft has been about acknowledgements). I thought it was a more serious concern for academics and consultants, but am now seeing the same concerns from corporate standards types and development engineers in other working groups. I have expressed this as a concern in private e-mail, but don't know what the answer is. - the IPR is to all the co-authors. Every person having contributed a word, a concept, a change, positively or negatively is a co-author. This also has some importance to show the document is not the work of an affinity group (as discussed in RFC 3774) but of a true WG. In my limited SDO experience, beyond IETF I am most familar with IEEE 802.1 practice, which is to list participants (at least, this is what appears in the most recent IEEE 802.1 standard appearing on Getieee802 at http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf), where the list is membership at the time of approval, and balloted at various times. Since we have no clue who the membership of an IETF working group is, I don't know how to do the equivalent thing here. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
On Mon, Jun 05, 2006 at 08:21:29PM -0400, Steven M. Bellovin wrote: More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. One of the complaints about ASN.1 is that it is an enabler of complexity. It becomes easy to specify some arbitrarily complex data structures, and very often with that complexity comes all sorts of problems. To be fair, though, the same thing can be said of XML (and I'm not a big fan of a number of specifications utilizing XML either, for the same reason), and ultimately, you can write Fortran in any language. Ultimately, I have to agree with Steve, it's not the encoding, it's going to about asking the right questions at the design phase more than anything else, at least as far as the protocol is concerned. As far as implementation issues, it is true that ASN.1 doesn't map particularly well to standard programming types commonly in use, although if you constrain the types used in the protocol that issue can be relative easily avoided (so would using XML, or a simpler ad-hoc encoding scheme). I don't think there is any right answer here, although my personal feelings about ASN.1 can still be summed up in the aphorism, Friends don't let friends use ASN.1, but that's mostly due to psychic scars caused by my having to deal with the Kerboers v5 protocol's use of ASN.1, and the feature and design bloat that resulted from it. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Schema languages for XML (Was: Best practice for data encoding?
I'll concur wrt the generality, flexibility, and power of XML as a data encoding. Considering comments on the ancestor thread, though, I'll also observe that the generality and flexibility are Not Your Friends if situations require encodings to be distinguished. The processing rules in X.690 that define DER relative to BER are expressed there within three pages (admittedly, excluding the cross-ref to X.680 for tag ordering); even though they may imply underlying complexity in implementation, their complexity in specification and concept seems vastly simpler than the issues that arise with XML canonicalization. --jl -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 3:51 AM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Schema languages for XML (Was: Best practice for data encoding? On Tue, Jun 06, 2006 at 09:50:22AM -0700, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 42 lines which said: At this point XML is not a bad choice for data encoding. +1 The problem in XML is that XML Schema was botched and in particular namespaces and composition are botched. I think this could be fixed, perhaps. There are other schema languages than the bloated W3C Schema. The most common is RelaxNG (http://www.relaxng.org/). In the IETF land, while RFC 3730 and 3981 unfortunately use W3C Schema, RFC 4287 uses RelaxNG. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Schema languages for XML (Was: Best practice for data encoding?
Title: RE: Schema languages for XML (Was: Best practice for data encoding? I would suggest that the problems with canonicalization in both cases stem from the fact that it was an afterthought. The original description of DER was a single paragraph. If iso required implementations before a standard was agreed I don't think it would have passed in that form, they would have used the indefinite length encoding for structures. Xml canonicalization went sour after people started to use namespace prefixed data. This caused the namespace scheme which is poorly designed to cross over into the data space. I would suggest that the best approach for data encoding today would be to make use of the xml infoset but think twice about using the xml encoding. -Original Message- From: Linn, John [mailto:[EMAIL PROTECTED]] Sent: Wed Jun 07 05:19:44 2006 To: Stephane Bortzmeyer; Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: RE: Schema languages for XML (Was: Best practice for data encoding? I'll concur wrt the generality, flexibility, and power of XML as a data encoding. Considering comments on the ancestor thread, though, I'll also observe that the generality and flexibility are Not Your Friends if situations require encodings to be distinguished. The processing rules in X.690 that define DER relative to BER are expressed there within three pages (admittedly, excluding the cross-ref to X.680 for tag ordering); even though they may imply underlying complexity in implementation, their complexity in specification and concept seems vastly simpler than the issues that arise with XML canonicalization. --jl -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 07, 2006 3:51 AM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Schema languages for XML (Was: Best practice for data encoding? On Tue, Jun 06, 2006 at 09:50:22AM -0700, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 42 lines which said: At this point XML is not a bad choice for data encoding. +1 The problem in XML is that XML Schema was botched and in particular namespaces and composition are botched. I think this could be fixed, perhaps. There are other schema languages than the bloated W3C Schema. The most common is RelaxNG (http://www.relaxng.org/). In the IETF land, while RFC 3730 and 3981 unfortunately use W3C Schema, RFC 4287 uses RelaxNG. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
The basic problem is that there is no way to acknowledge all the folks who helped, for the most general definition of contributor. One would have to keep track of every person who made a comment on the mailing list (whether the particular change ended up used or not) and everyone who spoke at the meeting. That is why it is common (but not mandatory) to acknowledge the working group that worked on the draft. This relates to the acknowledgement section more than the contributors section. Acknowledging folks who helped is a good idea. Particularly for a volunteer organization. But we can not and do not have to be fanatic about trying to acknowledge everyone. On a historical note, the acknowledgements section was intended for folks who wrote pieces, or folks who suggested useful ideas, or provided significant useful corrections, etc. The contributors section was introduced in conjunction with the effort to reduce the set of authors to those who wrote the primary text. So Contributors is usually used for those who wrote sections of text, but not enough to be authors. (The debate about whether we should ahve that distinction is a different discussion, please.) So we actually should be trying to be careful and thurough about the contributors section, since those are folks who wrote noticeably more than a single paragraph, and we ought to be able to tell who they are. Even then, mistakes will be made, and as far as I can tell it is not fatal. Yours, Joel M. Halpern At 07:47 AM 6/7/2006, Spencer Dawkins wrote: Perhaps I lead a sheltered life, but on two of these points... - Appendix A - some names seem to be missing. I could quote a small score of them? I do not know if there are written rules about the Acknowledgements or Credits section in a RFC. It seems quite variable between the RFCs. I am mentioned in draft-ietf-ltru-matching-14 for what I regard as a very small contribution and not in RFC 4408 where I feel that my contribution is more substantive. Dear Stephane, This may seem trivial, but IMHO quoting every contributor is important for several key reasons. - the IETF is made of paid and free volunteers. The reward of the free participants is their exposure. If we want top quality participants we must acknowledge their contributions. This is a real concern (I am a working group draft editor for a draft where probably 30 percent of the e-mail I've received on the draft has been about acknowledgements). I thought it was a more serious concern for academics and consultants, but am now seeing the same concerns from corporate standards types and development engineers in other working groups. I have expressed this as a concern in private e-mail, but don't know what the answer is. - the IPR is to all the co-authors. Every person having contributed a word, a concept, a change, positively or negatively is a co-author. This also has some importance to show the document is not the work of an affinity group (as discussed in RFC 3774) but of a true WG. In my limited SDO experience, beyond IETF I am most familar with IEEE 802.1 practice, which is to list participants (at least, this is what appears in the most recent IEEE 802.1 standard appearing on Getieee802 at http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf), where the list is membership at the time of approval, and balloted at various times. Since we have no clue who the membership of an IETF working group is, I don't know how to do the equivalent thing here. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On Wed, Jun 07, 2006 at 09:10:25AM -0400, Joel M. Halpern [EMAIL PROTECTED] wrote a message of 86 lines which said: the acknowledgements section was intended for folks who wrote pieces, or folks who suggested useful ideas, or provided significant useful corrections, etc. The contributors section was introduced in conjunction with the effort to reduce the set of authors to those who wrote the primary text. So Contributors is usually used for those who wrote sections of text, but not enough to be authors. These rules are perfectly reasonable (even if they would cost me my acknowledgment in draft-ietf-ltru-matching) but: 1) They do not seem to be written somewhere. I cannot find them in the RFCs talking about RFCs (meta-RFCs? IPODs?). 2) They are not currently applied or enforced, as anyone can see when comparing a RFC with the work in the WG which created it. (Not a big deal but good to keep in mind when you read an Ack section.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Hi, In all the documents that I participated or edited, I always keep track of all the inputs and comments received and unless they are just editorial comments (unless very extensive) include them in the ack section. It is a simple matter of gratitude and simply to achieve. For many reasons, including legal ones, all the co-authors should be explicitly listed with all their details in the authors section. I will say in alphabetic order ? One possible way to avoid some of the problems listing many co-authors, co-editors, etc., in the front page header could be so simple as not having any one. Being IETF work, at the end, that don't really cares so much. However, recognizing all kind of contributors (I'm not referring just all the WG members), is a must, as many people contributes with their own time and it possibly the only way to get some recognition, otherwise we will start missing more and more contributors sooner or later. Also, co-authors have the right to as for who should be acknowledged. For example, several documents I've participated have been only possible thanks to the funding of research programs, such as national ones or in Europe the IST-EC one. We have the obligation to get listed as co-authors and have a citation to that co-funding to be able to get our expenses paid, and nobody can oppose to that. Regards, Jordi De: Joel M. Halpern [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 07 Jun 2006 09:10:25 -0400 Para: ietf@ietf.org Asunto: Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) The basic problem is that there is no way to acknowledge all the folks who helped, for the most general definition of contributor. One would have to keep track of every person who made a comment on the mailing list (whether the particular change ended up used or not) and everyone who spoke at the meeting. That is why it is common (but not mandatory) to acknowledge the working group that worked on the draft. This relates to the acknowledgement section more than the contributors section. Acknowledging folks who helped is a good idea. Particularly for a volunteer organization. But we can not and do not have to be fanatic about trying to acknowledge everyone. On a historical note, the acknowledgements section was intended for folks who wrote pieces, or folks who suggested useful ideas, or provided significant useful corrections, etc. The contributors section was introduced in conjunction with the effort to reduce the set of authors to those who wrote the primary text. So Contributors is usually used for those who wrote sections of text, but not enough to be authors. (The debate about whether we should ahve that distinction is a different discussion, please.) So we actually should be trying to be careful and thurough about the contributors section, since those are folks who wrote noticeably more than a single paragraph, and we ought to be able to tell who they are. Even then, mistakes will be made, and as far as I can tell it is not fatal. Yours, Joel M. Halpern At 07:47 AM 6/7/2006, Spencer Dawkins wrote: Perhaps I lead a sheltered life, but on two of these points... - Appendix A - some names seem to be missing. I could quote a small score of them? I do not know if there are written rules about the Acknowledgements or Credits section in a RFC. It seems quite variable between the RFCs. I am mentioned in draft-ietf-ltru-matching-14 for what I regard as a very small contribution and not in RFC 4408 where I feel that my contribution is more substantive. Dear Stephane, This may seem trivial, but IMHO quoting every contributor is important for several key reasons. - the IETF is made of paid and free volunteers. The reward of the free participants is their exposure. If we want top quality participants we must acknowledge their contributions. This is a real concern (I am a working group draft editor for a draft where probably 30 percent of the e-mail I've received on the draft has been about acknowledgements). I thought it was a more serious concern for academics and consultants, but am now seeing the same concerns from corporate standards types and development engineers in other working groups. I have expressed this as a concern in private e-mail, but don't know what the answer is. - the IPR is to all the co-authors. Every person having contributed a word, a concept, a change, positively or negatively is a co-author. This also has some importance to show the document is not the work of an affinity group (as discussed in RFC 3774) but of a true WG. In my limited SDO experience, beyond IETF I am most familar with IEEE 802.1 practice, which is to list participants (at least, this is what appears in the most recent IEEE 802.1 standard appearing on Getieee802 at http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf), where the list
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On 06/07/2006 09:22 AM, Stephane Bortzmeyer allegedly wrote: These rules are perfectly reasonable (even if they would cost me my acknowledgment in draft-ietf-ltru-matching) but: 1) They do not seem to be written somewhere. I cannot find them in the RFCs talking about RFCs (meta-RFCs? IPODs?). 2) They are not currently applied or enforced, as anyone can see when comparing a RFC with the work in the WG which created it. (Not a big deal but good to keep in mind when you read an Ack section.) They should not be *rules*. If you try to formalize the definition of a contribution, then we get into eternal niggling. If you feel like you have been unjustly left out of an acknowledgments section in a specific draft or RFC, argue your case. Let's not have yet more process and procedure and administration for issues that don't affect running code. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On Wed, Jun 07, 2006 at 09:36:53AM -0400, Scott W Brim [EMAIL PROTECTED] wrote a message of 17 lines which said: If you feel like you have been unjustly left out of an acknowledgments section in a specific draft or RFC, Not at all. (You can read the whole thread to get the details but, as many people said, the Ack section has no practical consequences.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
Theodore Tso wrote: On Mon, Jun 05, 2006 at 08:21:29PM -0400, Steven M. Bellovin wrote: More precisely -- when something is sufficiently complex, it's inherently bug-prone. That is indeed a good reason to push back on a design. The question to ask is whether the *problem* is inherently complex -- when the complexity of the solution significanlty exceeds the inherent complexity of the problem, you've probably made a mistake. When the problem itself is sufficiently complex, it's fair to ask if it should be solved. Remember point (3) of RFC 1925. One of the complaints about ASN.1 is that it is an enabler of complexity. It becomes easy to specify some arbitrarily complex data structures, and very often with that complexity comes all sorts of problems. To be fair, though, the same thing can be said of XML (and I'm not a big fan of a number of specifications utilizing XML either, for the same reason), and ultimately, you can write Fortran in any language. Ultimately, I have to agree with Steve, it's not the encoding, it's going to about asking the right questions at the design phase more than anything else, at least as far as the protocol is concerned. As far as implementation issues, it is true that ASN.1 doesn't map particularly well to standard programming types commonly in use, although if you constrain the types used in the protocol that issue can be relative easily avoided (so would using XML, or a simpler ad-hoc encoding scheme). I don't think there is any right answer here, although my personal feelings about ASN.1 can still be summed up in the aphorism, Friends don't let friends use ASN.1, but that's mostly due to psychic scars caused by my having to deal with the Kerboers v5 protocol's use of ASN.1, and the feature and design bloat that resulted from it. Here's my down in the trenches observations about XML and to some degree ASN.1. XML gives me the ability to djinn up a scheme really quickly with as much or as little elegance as needed. If nothing else, XML quite rapidly allows me to hack up intpreters that would otherwise been another parsed text file casuality residing in /etc. And most likely, if they could read the previous text encoding, the XML is about as transparent. This is a very nice feature as it allows common parsers, leads to common practices about how to lay out simple things, and common understanding about what is right and wrong. So, for my standpoint XML is no more ad hoc parsers!, which is good from a complexity standpoint, especially when you look at how spare the base syntax is. That said, anything that requires nested structure, etc XML is probably just as inadequate as anything else. And who should be surprised? Don't blame the Legos that they self-assemble into a rocket ship. One big plus about XML is that I can just _read_ it and hack up pretty printers in trivial time. ASN.1 that is, um, abstract necessasrily needs to go through a translation layer which IMO is never as fun and convenient -- and absolutely discourages dilitante hacking (when is the last time you fiddled with an XML file vs. the last time you fiddled with ANS.1? never for the latter?). I guess that what part of what this devolves into is who we're writing these protocols/schemes for: machines or people? That, I think, is a huge false dilemma. We clearly are writing things for _both_ (the executors and the maintainers) ; the only question in my mind is whether an easy for human to maintain encoding is too inefficient on the wire for its task. In some cases it clearly is, but those cases are becoming the outliers -- especially at app layer -- as the march of memory and bandwidth plods on. So with all of these wars, the sexy overblown hype (yes of course XML can solve world hunger!) often eclipses the routine and mundane tasks of writing and maintaining a system (golly, I need a config file for this, it's been a while since I wrote a really crappy parser. woo woo!). C'est la vie. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
At 15:10 07/06/2006, Joel M. Halpern wrote: The basic problem is that there is no way to acknowledge all the folks who helped, for the most general definition of contributor. One would have to keep track of every person who made a comment on the mailing list (whether the particular change ended up used or not) and everyone who spoke at the meeting. Yes. This seems to be exactly what contributing means for the IETF mailing list environment, IPR wise. Some additional attention can be paid to ADs, reviewers, and IESG Member having worked in a detailed appeal (what IESG did for my appeal against the first part of BCP47). That is why it is common (but not mandatory) to acknowledge the working group that worked on the draft. This relates to the acknowledgement section more than the contributors section. In _this_ case we have an additional element which is that a single RFC BCP becomes a two RFC BCP. The people who contributed to the first RFC and the people who contributed to the former practice should be acknowledged. Otherwise, there is no reason why we would have a BCP. Acknowledging folks who helped is a good idea. Particularly for a volunteer organization. But we can not and do not have to be fanatic about trying to acknowledge everyone. Full agreement. In _this_ case we also have an additional key need: to externally demonstrate an IETF consensus, and its respect by the IESG. The currently listed names and the way the IESG does not respect the first part of BCP 47 (cf. my appeal) lead external people feel this text is biased. I am very concerned because I think this was but is no more true (the proposed text failed two IETF LCs, this one should not): there is a tough consensus that this text is acceptable for the Internationalized ASCII Internet. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Sites Support IPv6
Ray, On 6-jun-2006, at 16:31, Ray Pelletier wrote: I am pleased to report this 6th day of June 2006 that IETF FTP, Mail Web support IPv6. I was wondering: would it be possible to publish statistics about IPv4 vs IPv6 traffic for these services? Iljitsch (And this time the headers should have IPv6 in them...) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Acknowledgements section in a RFC (Was: Last Call:
JFC Morfin wrote: -- In _this_ case we have an additional element which is that a single RFC BCP becomes a two RFC BCP. The people who contributed to the first RFC and the people who contributed to the former practice should be acknowledged. Otherwise, there is no reason why we would have a BCP. -- In fact, there already is such an ack. There is a paragraph in that section (before the list of names): -- The contributors to [RFC3066bis], [RFC3066] and [RFC1766], each of which is a precursor to this document, made enormous contributions directly or indirectly to this document and are generally responsible for the success of language tags. -- Jordi wrote: -- In all the documents that I participated or edited, I always keep track of all the inputs and comments received and unless they are just editorial comments (unless very extensive) include them in the ack section. It is a simple matter of gratitude and simply to achieve. -- This was the policy used in this document (subject to editorial discretion), hence the recognition of the small contribution of Stephane Bortzmeyer. When this document was split from draft-ietf-ltru-registry-14 (aka RFC 3066bis), I cleared the list, inserted the above paragraph, and started to collect names again. And finally, Scott Brim wrote: -- They should not be *rules*. If you try to formalize the definition of a contribution, then we get into eternal niggling. If you feel like you have been unjustly left out of an acknowledgments section in a specific draft or RFC, argue your case. Let's not have yet more process and procedure and administration for issues that don't affect running code. -- +1 Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Spencer, This opens up yet another can of worms. Suppose that everybody who makes a comment on a draft (substantive, or otherwise) has to be listed and every one listed is bound by BCPs relating to IPR, copyright, etc. in RFC content. What happens if someone - perhaps having suggested that a word was misspelled - would prefer not to be bound by the BCPs (or perhaps is not permitted to be so bound)? Can they request to be left out? If they do, can an editor leave them out? It occasionally happens now that a draft departs from the original direction that some of the contributors wanted it to go, and - slightly less often - those that disagree with the outcome ask to be de-listed. There are good and reasonable reasons to allow this - especially as there may be very strong reactions from a particular employer that is seen as advocating something they do not intend to do. In such cases, these early contributors provided much of the content - even if the over-all outcome is not in line with their intentions. So, again, would we be able to omit their names? -- Eric -- -Original Message- -- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, June 07, 2006 7:48 AM -- To: ietf@ietf.org -- Subject: Re: Acknowledgements section in a RFC (Was: Last -- Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) -- -- Perhaps I lead a sheltered life, but on two of these points... -- -- - Appendix A - some names seem to be missing. I could -- quote a small -- score of them? -- -- I do not know if there are written rules about the -- Acknowledgements -- or Credits section in a RFC. It seems quite variable between the -- RFCs. I am mentioned in draft-ietf-ltru-matching-14 for -- what I regard -- as a very small contribution and not in RFC 4408 where I -- feel that my -- contribution is more substantive. -- -- Dear Stephane, -- This may seem trivial, but IMHO quoting every contributor -- is important for -- several key reasons. -- -- - the IETF is made of paid and free volunteers. The -- reward of the free -- participants is their exposure. If we want top quality -- participants we -- must acknowledge their contributions. -- -- This is a real concern (I am a working group draft editor -- for a draft where -- probably 30 percent of the e-mail I've received on the -- draft has been about -- acknowledgements). I thought it was a more serious concern -- for academics and -- consultants, but am now seeing the same concerns from -- corporate standards -- types and development engineers in other working groups. I -- have expressed -- this as a concern in private e-mail, but don't know what -- the answer is. -- -- - the IPR is to all the co-authors. Every person having -- contributed a -- word, a concept, a change, positively or negatively is a -- co-author. This -- also has some importance to show the document is not the -- work of an -- affinity group (as discussed in RFC 3774) but of a true WG. -- -- In my limited SDO experience, beyond IETF I am most familar -- with IEEE 802.1 -- practice, which is to list participants (at least, this -- is what appears in -- the most recent IEEE 802.1 standard appearing on Getieee802 at -- http://standards.ieee.org/getieee802/download/802.1AB-2005.p -- df), where the -- list is membership at the time of approval, and balloted -- at various -- times. -- -- Since we have no clue who the membership of an IETF -- working group is, I -- don't know how to do the equivalent thing here. -- -- Spencer -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
* * the acknowledgements section was intended for folks who wrote * pieces, or folks who suggested useful ideas, or provided significant * useful corrections, etc. The contributors section was introduced in * conjunction with the effort to reduce the set of authors to those * who wrote the primary text. So Contributors is usually used for * those who wrote sections of text, but not enough to be authors. * * These rules are perfectly reasonable (even if they would cost me my * acknowledgment in draft-ietf-ltru-matching) but: * * 1) They do not seem to be written somewhere. I cannot find them in the * RFCs talking about RFCs (meta-RFCs? IPODs?). The text in Section 2.12 of RFC223bis is intended to state these guidelines. See: ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt The RFC Editor would be happy to receive suggestions for augmentation or modification of the text in this section. Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On Wed, 7 Jun 2006, Spencer Dawkins wrote: Perhaps I lead a sheltered life, but on two of these points... snip - the IETF is made of paid and free volunteers. The reward of the free participants is their exposure. If we want top quality participants we must acknowledge their contributions. This is a real concern (I am a working group draft editor for a draft where probably 30 percent of the e-mail I've received on the draft has been about acknowledgements). I thought it was a more serious concern for academics and consultants, but am now seeing the same concerns from corporate standards types and development engineers in other working groups. I have expressed this as a concern in private e-mail, but don't know what the answer is. The entire archive of any WG list is saved and available, so comments made to the list are easy to track. Thoughtful comments and reviews published to the list should serve to document individual opinions and contributions. We use list traffic now to document objections, so I don't see why we can't use it to document WG member contributions. - the IPR is to all the co-authors. Every person having contributed a word, a concept, a change, positively or negatively is a co-author. This also has some importance to show the document is not the work of an affinity group (as discussed in RFC 3774) but of a true WG. In my limited SDO experience, beyond IETF I am most familar with IEEE 802.1 practice, which is to list participants (at least, this is what appears in the most recent IEEE 802.1 standard appearing on Getieee802 at http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf), where the list is membership at the time of approval, and balloted at various times. Since we have no clue who the membership of an IETF working group is, I don't know how to do the equivalent thing here. Maybe we can say that this is documented via public posting to the list - private comments made off list are just that - private comments. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
--On Wednesday, 07 June, 2006 12:33 -0400 Gray, Eric [EMAIL PROTECTED] wrote: Spencer, This opens up yet another can of worms. Suppose that everybody who makes a comment on a draft (substantive, or otherwise) has to be listed and every one listed is bound by BCPs relating to IPR, copyright, etc. in RFC content. They are so bound... read the Note Well. Whether they should be so listed is a separate issue. What happens if someone - perhaps having suggested that a word was misspelled - would prefer not to be bound by the BCPs (or perhaps is not permitted to be so bound)? Can they request to be left out? If they do, can an editor leave them out? Too bad. If they participate in the IETF at the level of either attending meetings or saying anything, they are stuck. While there are guidelines now (see Bob Braden's note) and guidelines can always be further tuned, I think we need to give some discretion to document editors about who should be listed --at least until and unless we have a clear definition of, e.g., WG membership. It occasionally happens now that a draft departs from the original direction that some of the contributors wanted it to go, and - slightly less often - those that disagree with the outcome ask to be de-listed. There are good and reasonable reasons to allow this - especially as there may be very strong reactions from a particular employer that is seen as advocating something they do not intend to do. In such cases, these early contributors provided much of the content - even if the over-all outcome is not in line with their intentions. So, again, would we be able to omit their names? I have often dealt with that issue in acknowledgements by being very explicit that all contributors may not agree with the conclusions reached as a consequence of their suggestions (or with their suggestions included). An even more extreme case exists than the ones that you mention: someone raises an issue and preference and the document is ultimately clarified to reflect exactly the opposite preference. In some of these cases, the document would not have addressed the topic at all had the issue not been raised. The person who raised the issue may still have made a contribution significant enough to justify acknowledgement but may have always been in violent disagreement with the conclusion reached by the IETF process about how to deal with it. The underlying problem here is not unique to the IETF. And people who don't want to contribute or be bound by the rules should avoid participation -- there isn't any whoops, I don't like the results so the rules should retroactively not apply to me and the fact that I participated at all should be erased option. Having such an option with regard to rule-conforming would result in chaos. Again, the Note Well is very clear about this (and there is a parallel discussion going in circles, perhaps parallel ones, in the IPR WG). john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
John, I disagree both in the belief that the Note Well is clear on this and the sense of your argument that anyone participating in any part of a discussion can be made retroactively responsible for the entire discussion. The Note Well is not clear because it makes sweeping statements about the way in which BCP 78 and 79 may apply to contributions. The obvious (but not clear) intent is that what you contribute is now subject to provisions of these BCPs that apply to contributions. What is both more subtle and not clearly excluded is that _only_ what you've contributed applies and that contributing to a work is not the same as authoring it. I refer directly to the required RFC inclusions that specifically use the word author and their rights and responsibilities with respect to IPR and copyrights. If I make a comment about a rev -01 version of a draft and stop participating in the work, I may not be held accountable for IPR I may know of but which did not enter into the text until sometime after I stopped looking at it. Similarly, if I object to work that has been done, you may not attach my name to it against my objections - unless either the Note Well, and the BCPs, both explicitly include a provision for implied consent. If that is the case, now, then it is most certainly not clear that it is. This is the negative side of the discussion going on. People are focusing on reasons why someone might want to be included in acknowledgements. I am merely pointing out that it is also possible that someone might not want this. -- Eric -- -Original Message- -- From: John C Klensin [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, June 07, 2006 1:53 PM -- To: Gray, Eric; Spencer Dawkins -- Cc: ietf@ietf.org -- Subject: RE: Acknowledgements section in a RFC (Was: Last -- Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) -- -- -- -- --On Wednesday, 07 June, 2006 12:33 -0400 Gray, Eric -- [EMAIL PROTECTED] wrote: -- -- Spencer, -- --This opens up yet another can of worms. Suppose that -- everybody who makes a comment on a draft (substantive, or -- otherwise) has to be listed and every one listed is bound by -- BCPs relating to IPR, copyright, etc. in RFC content. -- -- They are so bound... read the Note Well. Whether they should be -- so listed is a separate issue. -- --What happens if someone - perhaps having suggested that -- a word was misspelled - would prefer not to be bound by the -- BCPs (or perhaps is not permitted to be so bound)? Can they -- request to be left out? If they do, can an editor leave them -- out? -- -- Too bad. If they participate in the IETF at the level of either -- attending meetings or saying anything, they are stuck. While -- there are guidelines now (see Bob Braden's note) and guidelines -- can always be further tuned, I think we need to give some -- discretion to document editors about who should be listed --at -- least until and unless we have a clear definition of, e.g., WG -- membership. -- --It occasionally happens now that a draft departs from -- the original direction that some of the contributors wanted -- it to go, and - slightly less often - those that disagree -- with the outcome ask to be de-listed. There are good and -- reasonable reasons to allow this - especially as there may -- be very strong reactions from a particular employer that is -- seen as advocating something they do not intend to do. -- --In such cases, these early contributors provided much -- of the content - even if the over-all outcome is not in line -- with their intentions. So, again, would we be able to omit -- their names? -- -- I have often dealt with that issue in acknowledgements by being -- very explicit that all contributors may not agree with the -- conclusions reached as a consequence of their suggestions (or -- with their suggestions included). An even more extreme case -- exists than the ones that you mention: someone raises an issue -- and preference and the document is ultimately clarified to -- reflect exactly the opposite preference. In some of these -- cases, the document would not have addressed the topic at all -- had the issue not been raised. The person who raised the issue -- may still have made a contribution significant enough to justify -- acknowledgement but may have always been in violent disagreement -- with the conclusion reached by the IETF process about how to -- deal with it. -- -- The underlying problem here is not unique to the IETF. And -- people who don't want to contribute or be bound by the rules -- should avoid participation -- there isn't any whoops, I don't -- like the results so the rules should retroactively not apply to -- me and the fact that I participated at all should be erased -- option. Having such an option with regard to rule-conforming -- would result in chaos. Again, the Note Well is very clear about -- this
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Hi, In transferring responsibility for the Bridge MIBs to IEEE 802, we learned that the IETF has certain copyrights to documents that have been submitted to the IETF for IETF purposes. All other rights remain with the authors, and the IEEE had to contact the authors to get permission to do non-IETF things with the documents. The IETF has no authority to transfer the authors' rights to other organizations/persons for non-IETF purposes. So it is not important for IETF purposes for the IETF to define requirements about listing authors and contributors to IETF documents. It may be important to the authors and contributors and to others who want to ask those authors for permissions to do non-IETF things, or if the IETF decides it needs the rights to transfer rights to others for non-IETF purposes. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 1:53 PM To: Gray, Eric; Spencer Dawkins Cc: ietf@ietf.org Subject: RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) --On Wednesday, 07 June, 2006 12:33 -0400 Gray, Eric [EMAIL PROTECTED] wrote: Spencer, This opens up yet another can of worms. Suppose that everybody who makes a comment on a draft (substantive, or otherwise) has to be listed and every one listed is bound by BCPs relating to IPR, copyright, etc. in RFC content. They are so bound... read the Note Well. Whether they should be so listed is a separate issue. What happens if someone - perhaps having suggested that a word was misspelled - would prefer not to be bound by the BCPs (or perhaps is not permitted to be so bound)? Can they request to be left out? If they do, can an editor leave them out? Too bad. If they participate in the IETF at the level of either attending meetings or saying anything, they are stuck. While there are guidelines now (see Bob Braden's note) and guidelines can always be further tuned, I think we need to give some discretion to document editors about who should be listed --at least until and unless we have a clear definition of, e.g., WG membership. It occasionally happens now that a draft departs from the original direction that some of the contributors wanted it to go, and - slightly less often - those that disagree with the outcome ask to be de-listed. There are good and reasonable reasons to allow this - especially as there may be very strong reactions from a particular employer that is seen as advocating something they do not intend to do. In such cases, these early contributors provided much of the content - even if the over-all outcome is not in line with their intentions. So, again, would we be able to omit their names? I have often dealt with that issue in acknowledgements by being very explicit that all contributors may not agree with the conclusions reached as a consequence of their suggestions (or with their suggestions included). An even more extreme case exists than the ones that you mention: someone raises an issue and preference and the document is ultimately clarified to reflect exactly the opposite preference. In some of these cases, the document would not have addressed the topic at all had the issue not been raised. The person who raised the issue may still have made a contribution significant enough to justify acknowledgement but may have always been in violent disagreement with the conclusion reached by the IETF process about how to deal with it. The underlying problem here is not unique to the IETF. And people who don't want to contribute or be bound by the rules should avoid participation -- there isn't any whoops, I don't like the results so the rules should retroactively not apply to me and the fact that I participated at all should be erased option. Having such an option with regard to rule-conforming would result in chaos. Again, the Note Well is very clear about this (and there is a parallel discussion going in circles, perhaps parallel ones, in the IPR WG). john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
--On Wednesday, 07 June, 2006 14:22 -0400 Gray, Eric [EMAIL PROTECTED] wrote: John, I disagree both in the belief that the Note Well is clear on this and the sense of your argument that anyone participating in any part of a discussion can be made retroactively responsible for the entire discussion. I think were we disagree is about the notion that inclusion of one's name in an acknowledgement implies responsibility for any part of the discussion, much less all of it. The Note Well is not clear because it makes sweeping statements about the way in which BCP 78 and 79 may apply to contributions. The obvious (but not clear) intent is that what you contribute is now subject to provisions of these BCPs that apply to contributions. What is both more subtle and not clearly excluded is that _only_ what you've contributed applies and that contributing to a work is not the same as authoring it. To the extent to which you believe that the Note Well is unclear or defective, please take that to the IPR WG. I refer directly to the required RFC inclusions that specifically use the word author and their rights and responsibilities with respect to IPR and copyrights. If I make a comment about a rev -01 version of a draft and stop participating in the work, I may not be held accountable for IPR I may know of but which did not enter into the text until sometime after I stopped looking at it. I believe that is true. I also do not believe that an acknowledgement constitutes an assertion of accountability. But those are matters for counsel -- I will assert my beliefs about what ought to be happening here, but not about the legal implications of particular text. In particular, I do not believe that inclusion or exclusion from an acknowledgement implies an IPR claims or responsibilities at all: to do so would confound many centuries of publications history. An exception might(and probably would) arise if the contribution were identified in very specific terms, but those terms would bind that particular author/ contributor only to that text. As far as I recall, we have never included text in acknowledgements that says, e.g., Joe Blow contributed section 1.2.3.4 in its entirety and it is used with his permission, so the implications of that form are not relevant. Similarly, if I object to work that has been done, you may not attach my name to it against my objections - unless either the Note Well, and the BCPs, both explicitly include a provision for implied consent. If that is the case, now, then it is most certainly not clear that it is. It would clearly be inappropriate to list you as an author. Given our current peculiar definition of Contributor in the RFC sense, it would probably be inappropriate to include you as one of those, at least without permitting you to include a statement of dissent. It seems to me that you have no standing to object to the inclusion of your name in an acknowledgement if you, in fact, did something that the author thought was appropriate to acknowledge. I'd hope that, in normal circumstances, the author would honor your request to remove your name, but I can also see circumstances in which removing your name would be inappropriate. As one specific example, suppose the acknowledgements said Significant contributions to the topics discussed in this document came from an ad hoc group consisting of list of participants in that group. Now, adding a not all members of the group agree with the final conclusions represented in this document would be appropriate if true. But removing a name from the list of people who participated in the group, especially the name of someone who could be clearly determined from the group's mailing list to have actively participated, would simply be a lie and, IMO, completely inappropriate. This is the negative side of the discussion going on. People are focusing on reasons why someone might want to be included in acknowledgements. I am merely pointing out that it is also possible that someone might not want this. Understood. But that is precisely why listing in an acknowledgement must not have implications of responsibility for the whole document. And this discussion really belongs in the IPR WG. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
John, Agree. -- -Original Message- -- From: John C Klensin [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, June 07, 2006 3:04 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: RE: Acknowledgements section in a RFC (Was: Last -- Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) -- -- -- -- --On Wednesday, 07 June, 2006 14:22 -0400 Gray, Eric -- [EMAIL PROTECTED] wrote: -- -- John, -- --I disagree both in the belief that the Note Well is -- clear on this and the sense of your argument that anyone -- participating in any part of a discussion can be made -- retroactively responsible for the entire discussion. -- -- I think were we disagree is about the notion that inclusion of -- one's name in an acknowledgement implies responsibility for -- any part of the discussion, much less all of it. -- --The Note Well is not clear because it makes sweeping -- statements about the way in which BCP 78 and 79 may apply -- to contributions. The obvious (but not clear) intent is -- that what you contribute is now subject to provisions of -- these BCPs that apply to contributions. What is both more -- subtle and not clearly excluded is that _only_ what you've -- contributed applies and that contributing to a work is not -- the same as authoring it. -- -- To the extent to which you believe that the Note Well is unclear -- or defective, please take that to the IPR WG. -- --I refer directly to the required RFC inclusions that -- specifically use the word author and their rights and -- responsibilities with respect to IPR and copyrights. If I -- make a comment about a rev -01 version of a draft and stop -- participating in the work, I may not be held accountable -- for IPR I may know of but which did not enter into the text -- until sometime after I stopped looking at it. -- -- I believe that is true. I also do not believe that an -- acknowledgement constitutes an assertion of accountability. -- But those are matters for counsel -- I will assert my beliefs -- about what ought to be happening here, but not about the legal -- implications of particular text. In particular, I do not -- believe that inclusion or exclusion from an acknowledgement -- implies an IPR claims or responsibilities at all: to do so would -- confound many centuries of publications history. An exception -- might(and probably would) arise if the contribution were -- identified in very specific terms, but those terms would bind -- that particular author/ contributor only to that text. As far -- as I recall, we have never included text in acknowledgements -- that says, e.g., Joe Blow contributed section 1.2.3.4 in its -- entirety and it is used with his permission, so the -- implications of that form are not relevant. -- --Similarly, if I object to work that has been done, you -- may not attach my name to it against my objections - unless -- either the Note Well, and the BCPs, both explicitly include -- a provision for implied consent. If that is the case, now, -- then it is most certainly not clear that it is. -- -- It would clearly be inappropriate to list you as an author. -- Given our current peculiar definition of Contributor in the -- RFC sense, it would probably be inappropriate to include you as -- one of those, at least without permitting you to include a -- statement of dissent. It seems to me that you have no standing -- to object to the inclusion of your name in an acknowledgement if -- you, in fact, did something that the author thought was -- appropriate to acknowledge. I'd hope that, in normal -- circumstances, the author would honor your request to remove -- your name, but I can also see circumstances in which removing -- your name would be inappropriate. -- -- As one specific example, suppose the acknowledgements said -- Significant contributions to the topics discussed in this -- document came from an ad hoc group consisting of list of -- participants in that group. Now, adding a not all members of -- the group agree with the final conclusions represented in this -- document would be appropriate if true. But removing a name -- from the list of people who participated in the group, -- especially the name of someone who could be clearly determined -- from the group's mailing list to have actively participated, -- would simply be a lie and, IMO, completely inappropriate. -- --This is the negative side of the discussion going on. -- People are focusing on reasons why someone might want to be -- included in acknowledgements. I am merely pointing out that -- it is also possible that someone might not want this. -- -- Understood. But that is precisely why listing in an -- acknowledgement must not have implications of responsibility -- for the whole document. -- -- And this discussion really belongs in the IPR WG. -- -- john -- ___ Ietf mailing list Ietf@ietf.org
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
On Jun 7, 2006, at 12:03 PM, John C Klensin wrote: This is the negative side of the discussion going on. People are focusing on reasons why someone might want to be included in acknowledgements. I am merely pointing out that it is also possible that someone might not want this. Understood. But that is precisely why listing in an acknowledgement must not have implications of responsibility for the whole document. Guys: can you say majoring on the minors? Acknowledgments are used every way under the sun. Marshall Rose, in early SNMP documents, listed the entire working group by name as having contributed in some way. I generally list the people who send me comments on drafts, and if they send unusually large number of comments, I might say as much. The fact that they sent notes doesn't mean they agree - far from it. For example, RFC 4192 (procedures for renumbering) makes the following observation: This document grew out of a discussion on the IETF list. Commentary on the document came from [major snippage]. Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. I would be hard pressed to say that the folks who wrote to tell me I was wasting my time even thinking about the subject were responsible for what I wrote. No acknowledgment that I know of attributes responsibility to those who commented. That is invariably the domain of the authors, editors, or the working group that managed them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
On Wed Jun 7 15:37:28 2006, Michael Thomas wrote: I guess that what part of what this devolves into is who we're writing these protocols/schemes for: machines or people? That, I think, is a huge false dilemma. We clearly are writing things for _both_ (the executors and the maintainers) ; the only question in my mind is whether an easy for human to maintain encoding is too inefficient on the wire for its task. In some cases it clearly is, but those cases are becoming the outliers -- especially at app layer -- as the march of memory and bandwidth plods on. I think it's worth noting that nobody is preventing you from using XML over a compressed channel, which tends to increase XML's efficiency rather sharply. Compression also tends to make you look differently at protocol issues, because the repetitive, inefficient, protocol forms often compress equally well to, or even better than, a better structure - and they're also usually easier to handle. Wire efficiency, for the most part, needs to take place by avoiding the transmission of information entirely, rather than trying to second-guess the compression. As a rule, if you're moving strings around, or eliminating duplicates, within a single send of your protocol, you're probably wasting your time. In general, you want to be avoiding sending information at all. The only reason you have for worrying about representation for wire efficiency is if resource shortage prevents you from compression entirely - bear in mind this implies that resource shortage has already prevented you from encryption - generally a bad thing. As an example, IMAP and ACAP streams compress by around 70% on my client - and that's trying to be bandwidth efficient in its protocol usage. I've seen figures of 85% talked about quite seriously, too. So in answer to the original question, I'd say that the current best practise for data encoding has to be RFC1952, Deflate - beyond that, it really doesn't matter all that much. As an aside, whilst XMPP does provide a pure XML protocol, most protocols use XML as a payload, and use other forms to exchange protocol messages. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Disclaimer: IANAL, and this message is not intended as legal advice. Please, read RFC3979 for yourself, and if you have concerns as to what your obligations are or what you can get away with, consult a lawyer. On Wednesday, June 07, 2006 02:22:06 PM -0400 Gray, Eric [EMAIL PROTECTED] wrote: The Note Well is not clear because it makes sweeping statements about the way in which BCP 78 and 79 may apply to contributions. The Note Well is a notification that if you contribute, you have certain obligations. It is not a normative description of those obligations; for that, you need to refer to BCP 78 and 79. Those documents make it quite clear that you are obligated to disclose certain IPR if you make a contribution in _any_ form, including comments made in a meeting or on a mailing list, or to an IESG or IAB member, or to a portion of any working group, which is intended to cover a variety of ways in which people provide input outside the context of a formal meeting. BCP79 requires you to make disclosures of your or your employers IPR in a contribution you make, and normally in contributions you don't make but are aware of, even if you become aware of the IPR after the contribution is made. Not becoming aware of the IPR until after the document is published does not relieve you of the obligation to disclose it. Nor does having the contribution be made by someone else, even if they don't work for your company and/or are unaware of the IPR. participating in the work, I may not be held accountable for IPR I may know of but which did not enter into the text until sometime after I stopped looking at it. You're only obligated to make an IPR disclosure if the IPR is owned by you or your company and either (1) you made the contribution, or (2) the contribution was made in a discussion in which you are participating. If you stop participating in a discussion, you no longer have the responsibility to make IPR disclosures related to contributions made after you stop participating. Similarly, if I object to work that has been done, you may not attach my name to it against my objections - unless either the Note Well, and the BCPs, both explicitly include a provision for implied consent. If that is the case, now, then it is most certainly not clear that it is. Certainly, no one should be represented as supporting work which they do not support. It is entirely reasonable to request that your name be removed from the list of authors, if you no longer wish to perform the duties of an author, or from the list of contributors, if you did not make a contribution or don't want your contribution noted. Acknowledgements are more of a thanks for your input, and it's not really reasonable to tell authors that he can't acknowledge people whose input they found helpful - as long as an acknowledgement does not imply endorsement on the part of the person who is acknowledged. On the other hand, IMHO it would be even _more_ unreasonable for an author to refuse to remove the name of a person who did not want to be acknowledged. This is the negative side of the discussion going on. People are focusing on reasons why someone might want to be included in acknowledgements. I am merely pointing out that it is also possible that someone might not want this. And John's point is this: There may be legitimate reasons for not wanting to be acknowledged or listed as an author or contributor. However, having your name removed from the document does not change the fact of your contribution, or relieve you of your obligations with respect to that contribution. Now, you made specific reference to the IPR disclosure acknowledgement which is required by RFC3978 section 5.1 to be present in all I-D's. Your argument seems to be that this statement imposes an additional burden upon anyone listed as an author, and that one might want to be removed from the author list in order to be relieved of this burden. But if you read the acknowledgement carefully, the representation being made by the authors is that they are in compliance with BCP 79 section 6(*). Since compliance with that section is required for _anyone_ making a contribution to the IETF, being removed from the author list does _not_ relieve you of that burden - it simply allows you to avoid preiodically representing that you are meeting it. I completely agree that anyone who no longer wishes to be listed as an author of an I-D should be able to have their name removed. However, doing so does not remove your obligations relating to IPR disclosures. (*) The exact text quoted in RFC3978 is ... in accordance with Section 6 of BCP 79. Ordinarily, a reference is made to a BCP or STD number rather than to an RFC number when the goal is to produce a live reference that always refers to the latest approved version of the document. We usually avoid doing this in protocol specifications,
Re: Best practice for data encoding?
On 7-jun-2006, at 22:38, Dave Cridland wrote: I think it's worth noting that nobody is preventing you from using XML over a compressed channel, which tends to increase XML's efficiency rather sharply. [...] Wire efficiency, for the most part, needs to take place by avoiding the transmission of information entirely, rather than trying to second-guess the compression. Obviously adding compression doesn't help processing efficiency. I've long harbored the suspicion that a large percentage of the cycles in today's fast CPUs are burned up parsing various types of text. Does anyone know of any processing efficiency comparisons between binary and text based protocols? As an example, IMAP and ACAP streams compress by around 70% on my client - and that's trying to be bandwidth efficient in its protocol usage. I've seen figures of 85% talked about quite seriously, too. And you think that's a good thing? Now I understand why it takes me up to 10 minutes to download a handful of 1 - 2 kbyte emails with IMAP (+SSL) over a 9600 bps GSM data connection. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
I agree that the principle of avoiding interference is a general one that could be captured in this document. And I think this document had better be consistent in its application of principles. I will observe that as the documents are currently structured, the definitions of the individual streams discuss the details of handling those (inter)dependencies. Therefore, I believe your last sentence belongs as a comment on [EMAIL PROTECTED] and specifically on the document draft-klensin-rfc-independent . If this document is to capture *all* the specificallys of document stream interdependence, we will also have to capture the expectation that the IETF stream will not interfere with the IAB stream, and so on. I don't think that's effectively achievable or even maintainable in this document. Leslie. Brian E Carpenter wrote: Although I'm an IAB member, I'd rather make my one comment on this draft in public. I think it misses one point that should be mentioned. The easiest way to explain it is to suggest new text: 4.4. Avoiding interference between publication streams Although diversity of views and alternative solutions are common and will commonly be published, it would be highly undesirable for documents published in the different streams to interfere actively with each other, for example by specifying incompatible extensions to the same protocol or alternative uses for the same parameter value. For this reason, the procedures adopted for the four streams will include appropriate checks and balances to avoid such interference. Specifically, this will include a procedure (currently documented in [RFC3932]) to avoid Independent Submissions actively interfering with IETF Documents. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Sites Support IPv6
On Wed, 7 Jun 2006, Iljitsch van Beijnum wrote: (And this time the headers should have IPv6 in them...) It seems as if only incoming mails support v6, not outgoing. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Open mailing list for the discussion of Independent RFC Submissions Process
As part its role in supporting the RFC Editor function, the Internet Architecture Board (IAB) has created a public mailing list for the discussion of the RFC Independent Submissions process. The purpose of this discussion is to achieve consensus, in the coming weeks, on a process for fair and appropriate approval of independent submissions to the RFC series. These are separate from IETF, IAB or IRTF approved submissions. Individuals familiar with the RFC series and working in the Internet research and engineering community are invited to join this mailing list and participate. independentatietf.org https://www1.ietf.org/mailman/listinfo/independent There is an initial draft proposal, available at http://www.ietf.org/internet-drafts/draft-klensin-rfc-independent-02.txt Leslie Daigle, Chair, IAB. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4537 on Kerberos Cryptosystem Negotiation Extension
A new Request for Comments is now available in online RFC libraries. RFC 4537 Title: Kerberos Cryptosystem Negotiation Extension Author: L. Zhu, P. Leach, K. Jaganathan Status: Standards Track Date: June 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 6 Characters: 11166 Updates:RFC4120 See-Also: I-D Tag:draft-zhu-kerb-enctype-nego-04.txt URL:http://www.rfc-editor.org/rfc/rfc4537.txt This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS TRACK] This document is a product of the Kerberos WG Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
