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.
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
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
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
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.
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
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
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
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
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
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
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
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,
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?
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
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
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
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
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
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
*
* 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
*
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.
--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,
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
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
--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
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
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.
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
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:
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
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
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.
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
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
35 matches
Mail list logo
