James Carlson [EMAIL PROTECTED] writes:
YAO writes:
joining the IETF is luxury for individual.
[...]
it seems that IETF is becoming a wealthy club.
I agree it's a shame, but I disagree with your conclusions. The IETF
isn't a membership organization. You don't pay any dues to belong to
Ben Finney [EMAIL PROTECTED] writes:
Randy Presuhn [EMAIL PROTECTED] writes:
(1) What be the point of an update to RFC 1345? A modern developer
should be going directly to the ISO and Unicode documents for
reference.
RFC 1345 gives mnemonic strings for many useful characters, and there
Joe Abley [EMAIL PROTECTED] writes:
On 3-Aug-2007, at 08:25, Pekka Savola wrote:
Just an observation:
It's nice to note that the management appears to be busy with real
work. The last IAB minutes are from April 10, IAOC from March 1.
I have a stack of minutes to push up to the web page;
Peter Saint-Andre [EMAIL PROTECTED] writes:
Further, in-person meetings are so second-millennium. How about greater
use of text chat, voice chat, and video chat for interim meetings? Are
three in-person meetings a year really necessary if we make use of
collaborative technologies that have
Jeffrey Altman [EMAIL PROTECTED] writes:
Sam Hartman wrote:
Unless there is strong support for the more complex registration
process in the draft, we'd like to go to expert review.
The technical argument in favor of a review list, whether a special
list for this purpose or some pre-existing
Ted Hardie [EMAIL PROTECTED] writes:
At 6:41 PM +0200 6/14/07, Simon Josefsson wrote:
The ABNF syntax is the most important, since being compatible with the
technology requires that you follow the formal definition of the URL.
Implementations cannot integrate the ABNF as-is today
Dave Cridland [EMAIL PROTECTED] writes:
The conclusion remains that if the ABNF in this particular document
is
made available under a more liberal license, it will make
implementations of this particular document easier and more
reliable.
That should be in the interest of the IETF.
I
Dave Cridland [EMAIL PROTECTED] writes:
On Mon Jun 18 11:42:05 2007, Simon Josefsson wrote:
Several people consider this license insufficient to make it
possible to
include extracted material from RFCs into some implementations.
Given your reading, and given that the same thing must apply
Hi!
This document contains two sections that may be useful to extract and
include into implementations. I'm talking about section 11 (ABNF
specification) and Appendix A (Sample code). The rights granted by the
IETF license in RFC 3978/4748 in section 3.3, including the right to
extract code
Brian E Carpenter [EMAIL PROTECTED] writes:
On 2007-05-23 14:19, Jeroen Massar wrote:
...
Alternatively, directly look up
http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-claise-ipfix-export-per-sctp-stream-00.txt
(The above long formatted lines are not mine, 72 is a nice limit FYI)
Sorry
Frank Ellermann [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
I'm not sure it automatically imply that there are any indexes,
a log of who made what changes when, or a search function, etc.
Some wikis offer a revision history and a search function, e.g.
most openspf.org pages are based
PROTECTED]
To: Thierry Moreau [EMAIL PROTECTED]
Cc: ietf@ietf.org, [EMAIL PROTECTED],
Simon Josefsson [EMAIL PROTECTED], ietf@ietf.org, [EMAIL PROTECTED]
Subject: RE: Withdrawal of Approval and Second Last Call:
draft-housley-tls-authz-extns
On Fri, 27 Apr 2007, Thierry Moreau wrote:
Thus
Hi,
The document appear to contain several pages of random numbers and
systematic indices, page 32-47
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-raptor-object-08.txt:
,
| 5.6. Random Numbers
|
|The two tables V0 and V1 described in Section 5.4.4.1 are given
|below.
The plan says that the primary form of communication with the community
will be in the form of a public Wiki. A Wiki is unfortunately not a
precise term. I'm not sure it automatically imply that there are any
indexes, a log of who made what changes when, or a search function, etc.
I would
-- Forwarded message --
Date: Thu, 19 Apr 2007 16:21:50 -0400 (EDT)
From: Dean Anderson [EMAIL PROTECTED]
To: Simon Josefsson [EMAIL PROTECTED]
Cc: Mark Brown [EMAIL PROTECTED], [EMAIL PROTECTED],
ietf@ietf.org, [EMAIL PROTECTED]
Subject: Re: Withdrawal of Approval and Second Last
Mark Brown [EMAIL PROTECTED] writes:
However, if I understand the license correctly, it seems incompatible
with free software licenses. The RedPhone license contains:
1. General Use License
Upon request, RedPhone Security will provide a worldwide,
nonexclusive, fully-paid,
[EMAIL PROTECTED] writes:
The authors asked for a week delay while they prepared a new IPR
disclosure. That disclosure seems to have hit the IETF servers
Ah, good. For easy reference, the new IPR disclosure is available
from:
Brian E Carpenter [EMAIL PROTECTED] writes:
Simon,
Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having sent a postcard for the
style of RF license you are objecting to?
Brian, two responses:
1) You seem to assume that GPL implementers
Simon Josefsson [EMAIL PROTECTED] writes:
There are examples where companies won't respond to requests for these
type of RF patent licenses. A recent example that came to mind was
related to the BOCU patent by IBM:
http://permalink.gmane.org/gmane.text.unicode.devel/23256
A better URL
Brian E Carpenter [EMAIL PROTECTED] writes:
On 2007-04-11 10:08, Simon Josefsson wrote:
Brian E Carpenter [EMAIL PROTECTED] writes:
Simon,
Can you identify any instance of a non-profit GPL implementor or
distributor being sued for not having sent a postcard for the
style of RF license you
Jari Arkko [EMAIL PROTECTED] writes:
Simon,
Do you have examples of licenses/IPR declarations that work better with
GPL and other forms of open source? Something for Mark and the rest
of us to use as a model, perhaps?
Jari, thank you for asking!
I am working on a document with guidelines
Jari Arkko [EMAIL PROTECTED] writes:
Ok. But let me clarify my question. I was specifically after running
code that
has worked well in some case, and not so much specific new text. (Running
code would show that at least some open source project was OK with the
license and that at least some
Brian E Carpenter [EMAIL PROTECTED] writes:
On 2007-04-11 11:34, Arnt Gulbrandsen wrote:
Just one comment:
Brian E Carpenter writes:
On 2007-04-11 10:08, Simon Josefsson wrote:
What typically happens in practice, among good-faith
practitioners, is that there won't be any GPL (or Apache
Scott W Brim [EMAIL PROTECTED] writes:
On 04/11/2007 05:22 AM, Simon Josefsson wrote:
I am working on a document with guidelines for free standards in the
IETF
Please don't use free standards this way. The IETF produces free
standards.
According to what definition of 'free standards
Sam Hartman [EMAIL PROTECTED] writes:
Hi. I'm sitting here reviewing changes to a document to see if I can
last call it.
As part of a response to AD review comments, one of the references
were changed. This document uses numeric references. Starting at
reference 16, everything was
Steven M. Bellovin [EMAIL PROTECTED] writes:
On Thu, 05 Apr 2007 22:19:11 +0200
Simon Josefsson [EMAIL PROTECTED] wrote:
Sam Hartman [EMAIL PROTECTED] writes:
Hi. I'm sitting here reviewing changes to a document to see if I
can last call it.
As part of a response to AD review
On 4 apr 2007, at 00.45, Mark Brown wrote:
Harald,
I want to apologize again for screwing up the IPR disclosure process.
Normal IPR disclosure process is to alert the IETF community via
the IETF
website that a patent has been filed. I mistakenly thought that
adding the
boilerplate IPR
legal
advice.
In short, I am working to create a royalty-free license grant -- hopefully I
can disclose it next week. With some luck, it will clarify the situation.
I look forward to reading it!
Best regards,
Simon
Best regards,
mark
-Original Message-
From: Simon Josefsson
I don't care strongly about the standards track status. However,
speaking as implementer of the protocol: If the document ends up as
informational or experimental, I request that we make an exception and
allow the protocol to use the already allocated IANA protocol
constants. That will avoid
Sam Hartman [EMAIL PROTECTED] writes:
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon I don't care strongly about the standards track status.
Simon However, speaking as implementer of the protocol: If the
Simon document ends up as informational or experimental, I
Nicolas Williams [EMAIL PROTECTED] writes:
Alexey Melnikov made some comments in private. They should probably go
to the ietf@ietf.org list. Their gist: there should be an IANA registry
of channels with channel bindings, their specifications, and a
well-known string to be prefixed to said
Hi!
I started a review by going through the reference section. There
seems to be some editing left to do...
There are reference to old documents, including:
RFC 2279 - RFC 3629
RFC 1750 - RFC 4086
There are normative reference to non-standards track RFCs, including:
RFC 1641
RFC 1951
Pekka Savola [EMAIL PROTECTED] writes:
On Mon, 12 Mar 2007, The IESG wrote:
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
...
Working Group Summary
This document set was not produced by an IETF working group, but by an
individual. IETF
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Arguments on complexity are too easy to make. Every time a proposal
is made I hear the complexity argument used against it. Everything
we do is complex. Computers are complex. Committee process usually
increases complexity somewhat.
If an
Harald Alvestrand [EMAIL PROTECTED] writes:
3.3.a.E gives this authorization, but excluding patents.
There seems to be disagreement about that. Is there support for
updating BCP 78 to clarify the above?
There is, in the form of approving -outbound and -inbound. See
resolution of issues
Brian E Carpenter [EMAIL PROTECTED] writes:
I would refer you to the IETF Trust FAQ on RFC copyright,
http://trustee.ietf.org/24.html, point 6 and point 9.
Interesting. Point 6 seem incorrect to me, as there is nothing in BCP
78 that permits computer code extracts from RFC for third parties.
Randy Presuhn [EMAIL PROTECTED] writes:
Hi -
From: Simon Josefsson [EMAIL PROTECTED]
To: Joel M. Halpern [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Sent: Saturday, January 13, 2007 12:38 PM
Subject: Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation
X(ASN.X
Steven M. Bellovin [EMAIL PROTECTED] writes:
And as you very well know, the IPR working group is fixing the
problem. I think a pointer to the archives there would have sufficed
(or at least a mention of the discussion and status).
The mailing list archives doesn't contain a clear description
Hi! These documents contains normative ASN.1 modules which, if I
understand the documents correctly, is typically included in
implementations of this standard. Is that correct?
The modules contain this notice:
-- Copyright (C) The IETF Trust (2006). This version of
-- this ASN.1 module
modifiablity of the code, it
should be the code, and not this entire document or any portion of
it.
That is up to the each author to decide, of course.
Thanks,
Simon
Yours,
Joel M. Halpern
At 05:21 AM 1/13/2007, Simon Josefsson wrote:
Hi! These documents contains normative ASN.1 modules
Adrian Farrel [EMAIL PROTECTED] writes:
But note that the current version of the tracker does not raise the
DISCUSS with anyone. It simply logs it.
I agree, and think this is an important observation.
This lack of communication may cause friction. IESG members raise
issues, which ends up the
Adrian Farrel [EMAIL PROTECTED] writes:
By the way, would it be possible for all DISCUSSes and COMMENTs for
I-Ds originated by a working group to be *automatically* copied to the
mailing list of the working group? The reasons are:
- the WG chairs, editors, and interested parties should
not
Ray Pelletier [EMAIL PROTECTED] writes:
All;
More than 1,250 of you attended IETF 65 in Dallas and many others
attended sessions remotely. Yet only 155 of you have responded to a
survey intended to make future meeting experiences more successful.
There are only 74 days left before IETF 66
Jeffrey Hutzelman [EMAIL PROTECTED] writes:
On Thursday, April 20, 2006 03:05:43 PM +0200 Simon Josefsson
[EMAIL PROTECTED] wrote:
An example of the type of change that appears to be just a small
correction from one perspective but may be problematic from another
was the correction
In general, I think some of the specific recommendations in section 4
are poorly researched. I think it is bad advice to even suggest
people to look into the solution outlined in section 4.3. It seems to
me that adopting the approach would break backwards compatibility in
Unicode for most
Cullen Jennings [EMAIL PROTECTED] writes:
On 4/10/06 6:34 PM, John C Klensin [EMAIL PROTECTED] wrote:
--On Tuesday, 11 April, 2006 11:26 +1000 Mark Andrews
[EMAIL PROTECTED] wrote:
On 4/10/06 4:31 PM, Mark Andrews [EMAIL PROTECTED]
wrote:
Did the base32 extended hex version get used in
Hi Cullen, thanks for your review! Sorry for the delay in answering
this, I was on vacation.
Cullen Jennings [EMAIL PROTECTED] writes:
There seems to be two (or more) common base 64 encoding alphabets. Could we
enumerate the alphabets used in at least standards track RFCs and give each
one a
Andy Bierman [EMAIL PROTECTED] writes:
my $0.02:
Nothing -- not in the current meeting format.
A more workable model would be to treat the current
type of meeting as an Annual Plenary, full of Power-Point
laden 2 hour BOFs, and status meetings of almost no value
in the production of
Mohsen BANAN [EMAIL PROTECTED] writes:
The Free Protocols Foundation
Policies and Procedures
This looks like a useful initiative, although I cannot find any
discussion of what copying conditions you'll use on documents. Can
you clarify this?
I believe it is
How about updating the document with the new license, and ask for a
IETF-wide last call on it?
If anyone has a problem with a license that make it possible for
everyone to use the code in the document, they can tell the IESG the
reasons.
I really don't understand why making this change to the
that satisfy your concerns? The new wording is similar to the
phrasing found in the comparable statement in punycode's RFC 3492.
Tony Hansen
[EMAIL PROTECTED]
Simon Josefsson wrote:
The license in section 1.1 reads:
Royalty free license to copy and use this software is granted
author or version information.
would that satisfy your concerns? The new wording is similar to the
phrasing found in the comparable statement in punycode's RFC 3492.
Tony Hansen
[EMAIL PROTECTED]
Simon Josefsson wrote:
The license in section 1.1 reads:
Royalty free
The IESG [EMAIL PROTECTED] writes:
Note to the RFC Editor
To resolve the concerns with the term open source, please make the
following changes:
In the Abstract:
OLD:
The purpose of this document is to make open source code
performing these hash functions
Sam Hartman [EMAIL PROTECTED] writes:
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon Harald Tveit Alvestrand [EMAIL PROTECTED] writes:
--On tirsdag, desember 06, 2005 13:07:50 +0100 Simon Josefsson
[EMAIL PROTECTED] wrote:
I'd feel more comfortable
Lucy E. Lynch [EMAIL PROTECTED] writes:
On Thu, 8 Dec 2005, Simon Josefsson wrote:
Sam Hartman [EMAIL PROTECTED] writes:
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon Harald Tveit Alvestrand [EMAIL PROTECTED] writes:
--On tirsdag, desember 06, 2005 13:07:50 +0100
Lucy E. Lynch [EMAIL PROTECTED] writes:
Updated - see:
http://koi.uoregon.edu/~iaoc/docs/IETF-Trust-12-08-05.pdf
Thanks!
The Trust (acting through the Trustees) shall have the right to
grant licenses for the use of the Trust Assets on such terms,
subject to Section 7.1, as the
Brian E Carpenter [EMAIL PROTECTED] writes:
Lucy E. Lynch wrote:
On Thu, 8 Dec 2005, Simon Josefsson wrote:
Sam Hartman [EMAIL PROTECTED] writes:
I think it is sufficient the trust be able to operate under any set of
outbound rights we come up with.
That won't be possible, given the current
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Its purpose is to give the IETF control of its own IPR, which
has previously been held by 3rd parties. (That's not the
legal statement of purpose in the formal Trust Agreement.)
What we
Harald Tveit Alvestrand [EMAIL PROTECTED] writes:
--On tirsdag, desember 06, 2005 13:07:50 +0100 Simon Josefsson
[EMAIL PROTECTED] wrote:
I'd feel more comfortable if the outbounds right issue was settled,
before all IPR is signed away to some external body that, to me, it
seem unclear
Brian E Carpenter [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Its purpose is to give the IETF control of its own IPR, which has
previously been held by 3rd parties. (That's
The text in section 9.5 appear to me to make it permanently impossible
to incorporate portions of RFC in both free or proprietary products.
I believe that is unacceptable, and that it is counter to the needs of
many in the IETF community.
In the IPR WG, I have documented that implementations of
Simon Josefsson wrote:
The text in section 9.5 appear to me to make it permanently impossible
to incorporate portions of RFC in both free or proprietary products.
I believe that is unacceptable, and that it is counter to the needs
of
many in the IETF community.
In the IPR WG, I have
Steven M. Bellovin [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Bill
Fenner writes:
On 11/14/05, Stewart Bryant [EMAIL PROTECTED] wrote:
I would not mind swapping from to an XML package
provided it supported change-tracking, embedded comments,
highlighting, WYSWYG display, edit
I think that is a good point. A variation on that theme is that the
IETF is no longer run by people who actually implement protocols. The
relevance and impact of the IETF on what is actually used on the
Internet is marginalized through that change of membership. The
attitude of That is not how
Brian E Carpenter [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
Marshall Eubanks [EMAIL PROTECTED] writes:
On Thu, 14 Jul 2005 18:08:45 +0200
Simon Josefsson [EMAIL PROTECTED] wrote:
Brian E Carpenter [EMAIL PROTECTED] writes:
We propose that, for an initial period of 6 months
Brian E Carpenter [EMAIL PROTECTED] writes:
The two points are linked. The IESG gets to make some decisions about
people. X is a lousy WG chair, but Y is the only plausible replacement,
and she works for Z so would have a commercial interest in the
outcome. So we have to put up with X. I think
Brian E Carpenter [EMAIL PROTECTED] writes:
We propose that, for an initial period of 6 months, a member of
the community will be added to regular IESG meetings as a recording
secretary who will write narrative minutes of the discussions,
which will be posted publicly after IESG review for
Marshall Eubanks [EMAIL PROTECTED] writes:
On Thu, 14 Jul 2005 18:08:45 +0200
Simon Josefsson [EMAIL PROTECTED] wrote:
Brian E Carpenter [EMAIL PROTECTED] writes:
We propose that, for an initial period of 6 months, a member of
the community will be added to regular IESG meetings
Iljitsch van Beijnum [EMAIL PROTECTED] writes:
You can't do a text search on MP3s, listening is slower than reading
and language issues tend to be tougher with spoken language than they
are with written language.
Making audio recording available doesn't prevent also having a written
Kurt D. Zeilenga [EMAIL PROTECTED] writes:
It is my recommendation that the mandatory-to-implement
strong authentication mechanism for this protocol be either:
DIGEST-MD5 (with a mandate that implementations
support its data security layers)
TLS+PLAIN (with a
John C Klensin [EMAIL PROTECTED] writes:
To that end, since CRAM-MD5 is very widely deployed, I'd like to
see a much stronger justification for removing it than matters
of taste.
Seconded.
In the programs I use, mostly centered around e-mail and SMTP/IMAP,
CRAM-MD5 is the normal
Sam Hartman [EMAIL PROTECTED] writes:
Hi, folks. The IESG has received a last call comment recommending
that the new rc4 cipher for ssh be published as informational rather
than as a proposed standard because of weaknesses in rc4. It would be
inappropriate to make a decision based on one
I have not seen this apparently IETF related Unicode news mentioned
here, so FYI:
If anyone is interested in Unicode normalization issues, especially
wrt to Stringprep or Internationalized Domain Names (IDN), you might
be interested in a current public review issue in the UTC:
Issue #61
[EMAIL PROTECTED] (scott bradner) writes:
For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation.
For Kerberos, I want to be able to use the ASN.1 schema in my
implementation, and copy the terminology section into my manual.
For SASL, I
Vernon Schryver [EMAIL PROTECTED] writes:
From: Eric S. Raymond [EMAIL PROTECTED]
Your two people to go to on this would be RMS (representing the FSF)
or me (representing the OSI); between us I believe we can speak for
over 95% of the community.
I hate it when elected politicans presume to
There seem to be some misunderstanding here, free software is not
non-commercial. If someone wants to put restrictions of their ideas
on commercial competitors, that prevent the idea from being used in
free software as well. The rights associated with free software are
granted to commercial
[EMAIL PROTECTED] (scott bradner) writes:
there seems to be an assertion of evil intent here that is not the case
What gave you that idea? IMHO, let's leave intent for some other
discussion, and focus on the license.
After having read the discussion for the past few days, I still see no
Harald Tveit Alvestrand [EMAIL PROTECTED] writes:
h.
--On 7. oktober 2004 13:12 +0200 Simon Josefsson [EMAIL PROTECTED] wrote:
As far as I can tell, those rights are only granted to the ISOC and
the IETF, not third parties.
Solely for the purpose of using the term in RFC 3667
Eliot Lear [EMAIL PROTECTED] writes:
Simon,
What is your goal, here? What is it you want to do that you can't do
because of either RFC 3667 or RFC 2026?
Eliot,
a few examples:
For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation.
For Kerberos,
Francis Dupont [EMAIL PROTECTED] writes:
= I understand better your concern: the problem is about pieces of
code which can be extracted from an RFC, the cannonical example is
a MIB. This is covered in RFC 3667 by 5.2, 5.6 and 7.1e which I
give here:
e. the right to let third parties
[EMAIL PROTECTED] (scott bradner) writes:
If you extract, say, a C header file, or an ASN.1 schema, from an RFC
into an application, I believe that may be regard as a derivative
work.
see RFC 3667 Section 3.3 (a) (E)
a. To the extent that a Contribution or any portion thereof is
First, thanks for your two well written posts. They were the first in
this thread that reflect views that I share. Over the past week, I've
read both the O and C proposals, and it seems to me they both fail
to properly address the problems you bring up. Consequently, in the
straw poll, I didn't
[EMAIL PROTECTED] (scott bradner) writes:
but according to RFC 3667, the only
organization permitted to produce such derivative works would be
ISOC/IETF.
this is the way that its been since rfc 2026
The 2026 copyright notice include:
This document and translations of it may be copied
[EMAIL PROTECTED] (scott bradner) writes:
the text you quoted says
derivative works that comment on or otherwise explain
it or assist in its implmentation may be prepared, copied,
note that it is restricted to derivative works that comment on or
otherwise explain it or assist in its
Zefram [EMAIL PROTECTED] wrote almost a year ago:
1. A related issue, which I raised last time this was discussed but
was never addressed: there's a general extension mechanism, but no
reasonable use for it. This URI type should express solely a class,
name, type tuple; the
The document [1] specify a mode of encryption that has not, to my
knowledge, been used anywhere else: CBC-CTS with IV-carry. The
document does not reference any standard work that define it, so it
appears the document authors are not aware of prior use of it either.
There is no analysis of the
Zefram [EMAIL PROTECTED] wrote a few months ago:
I was referring to RFC2673 bit labels. Consider also what should be
done for other EDNS0 extended label types (RFC2671).
After doing some research, I discovered that IESG has reclassified
binary labels from proposed standard to experimental,
Paul Vixie [EMAIL PROTECTED] writes:
This view limit the usefulness of the URI, as it cannot be used to
refer to, e.g., not-yet delegated data. It can be useful to use DNS
URIs to denote DNS data in a delegation request, to indicate where the
new data will be placed, so it can be checked for
Paul Vixie [EMAIL PROTECTED] writes:
very well. then i request that you remove the hostport from the syntax.
The rationale being?
you said it best, earlier:
... Furthermore, DNS URIs do not require the use of the DNS protocol at
all, it just denote a DNS resource. ...
a dns
Zefram [EMAIL PROTECTED] writes:
This touches on an issue that I've been wondering about. I'm not entirely
clear on what the dnsqueryelement extension mechanism is for. What kind
of information might it represent? If the URI scheme is intended purely
to represent a name,type,class tuple
Zefram [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
one added some text to clarify that it was actually intended to allow
for zero length dnsname's (to denote the DNS root).
This is technically correct, according to RFC 1034, but will be confusing.
dns: intuitively looks incomplete. It's
Paul,
Thank you for the comments. Answers inline below.
Paul Vixie [EMAIL PROTECTED] writes:
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by
Andrew, I have incorporated your first suggestion, and for the second
one added some text to clarify that it was actually intended to allow
for zero length dnsname's (to denote the DNS root). Let me know if
you believe further modifications would improve the document. As for
the RD issue, I
Paul Vixie [EMAIL PROTECTED] writes:
...
Furthermore, DNS URIs do not require the use of the DNS protocol at
all, it just denote a DNS resource. DNS URIs can be resolved via HTTP
or something else. Having the RD bit present is a hint to the DNS
protocol; the RD bit has no connection with
One topic that is important to some people appears to be missing from
this document: what licensing scheme the Unicode Consortium uses for
their standards. It would be useful to include a discussion on the
differences between how the Unicode standard and IETF documents can be
(re-)distributed and
John Stracke [EMAIL PROTECTED] writes:
The CERT extension to DNS allows to place there a URI, a URI is smaller
than
a cert and stays in a udp packet.
Bootstrap problem: how can you trust the results of the URI?
The URI can contain a hash (fingerprint) of the target data. C.f. TLS
extensions
Dave Crocker [EMAIL PROTECTED] writes:
the architecture of IDN defined in the above three documents
does not solve the traditional and simplified Chinese character
variant problem: it's a half-baked solution for Chinese users.
It has never been a goal of IDN to create equivalence between
Gordon Mohr [EMAIL PROTECTED] writes:
There are multiple Base32 alphabets floating about
in Internet-Drafts. For example,
...
This discussion contained some good points, I hope the updates version
of this document includes them. In particular, I've added a URL and
Filename safe base64
201 - 298 of 298 matches
Mail list logo
