On 7 December 2011 18:08, Dave CROCKER d...@dcrocker.net wrote:
here's the cryptic list of terms that covers it:
Administration
Not limited to http://trustee.ietf.org/minutes.html, but it's
an interesting place to get a rough idea confirming Dave's list;
and why it is not a part of
On 5 December 2011 04:27, Cameron Byrne wrote:
[they = the IETF]
they underscored that point by not rejecting various past attempts at
expanding private ipv4 space like 240/4.
Sorry. S/not rejecting/rejecting/
ACK. The last state I'm aware of is that the 240/4 addresses minus one
were and
On 5 December 2011 19:00, David Conrad d...@virtualized.org wrote:
[IETF and 240/4]
Does it actually matter?
Dunno, I can't judge it. But I'd be seriously disappointed if any
hard- or software on my side won't let me participate in any 240/4
experiments, for all possible definitions of
On 3 December 2011 01:47, Mark Nottingham m...@mnot.net wrote:
1.2
worth pointing out that 'reserved' and 'unreserved' are formally
defined in 1.5, to stop people reaching for RFC3986.
If this is an issue, I'd actually prefer to place the notational
conventions section higher in the
On 30 November 2011 00:44, Mark Nottingham m...@mnot.net wrote:
Not sure what you're saying here; the URI escape syntax is % HEXDIG HEXDIG.
ACK, sorry for the confusion, I used the same ABNF hex. constructs as in
the literals section for the square brackets.
If the literal character [ occurs
On 1 December 2011 05:09, Murray S. Kucherawy m...@cloudmark.com wrote:
so long as experimental-status drafts are allowed to make IANA
registrations. (I thought they weren't, which is why it is the
way it is right now.)
Depends on the registry, some registrations need standards track,
others
Hi, that's an important and good draft. Some editorial nits:
In section 2.1 you use CTL, DQUOTE, and SP in a comment.
Please add these terms to the ABNF imports in section 1.5.
In section 1.3 you mention WSDL, WADL and OpenSearch.
Please add informative references and expand the acronyms.
On 27 November 2011 14:17, Eric Burger ebur...@standardstrack.com wrote:
Naah. We should update the 72-character ASCII limit to 40-characters.
Not only will that work for all of these mobile devices, it will work
on a TRS-80, too.
+1
While I hate all incarnations of Proprietary Data Format
On 27 November 2011 20:38, John C Klensin john-i...@jck.com wrote:
I'm willing to write up either an extension/update to RFC3676 or
a new subtype if there is enough expression of interest (not
just the two of us) to indicate that such a proposal would be
likely to go somewhere.
As Gmail web
On 15 November 2011 18:56, Noel Chiappa j...@mercury.lcs.mit.edu wrote:
Gee, I don't see my OS listed on that page. What do I do know?
Let DuckDuckGo tell you what it knows about Powerpoint viewer ubuntu.
FWIW I like ppt(x) better than pdf, anything pdf is huge. For simple
slides (x)html or
On 15 November 2011 19:28, Martin Rex m...@sap.com wrote:
And where is the download URL for an officially *FREE* license
of Microsoft Windows that is a prerequisite for this player?
http://www.microsoft.com/download/en/details.aspx?displaylang=enid=11575
Free as in 120 days and you can
On 15 November 2011 20:33, Martin Rex m...@sap.com wrote:
You mean free as in
Expires: This image will shutdown and become completely unusable
on November 17, 2011.
Yes, or rather, EAGAIN on November 18, that should give you the
next 120 days period for XP images. AFAIK the Vista images are
On 2 November 2011 15:40, Hadriel Kaplan wrote:
I haven't heard anyone raise complaints about
WebEx, which is not only a proprietary solution,
but also requires installing a plugin.
Thanks for info, I had no clue what this might be.
The other thingy at least offered some info. I'd
also like
On 31 October 2011 20:57, IETF Journal wrote:
The new version of the IETF Journal (Volume 7,
Issue 2) is now available online at:
http://isoc.org/wp/ietfjournal/?cat=5329
BTW, I liked your IETF Ornithology: Recent Sightings. A
subscription as news feed worked for me.
-Frank
On 28 October 2011 16:36, Randy Bush wrote:
we don't have enough real work to do?
Clean up is necessary work. Some hours ago
I tried to understand a discussion about the
ISE (independent stream), and gave up on
it when the maze of updates obsoleting RFCs
which updated other RFCs turned out to
On 14 October 2011 18:03, J.D. Falk wrote:
I'm okay with either, with a slight preference for including it in the
Acknowledgements section. MAAWG understands that this kind of boilerplate is
unusual for IETF documents.
Should I submit a new draft with these changes?
I'd still prefer
On 14 October 2011 20:28, John Levine wrote:
Hi John,
you believe that there is another large organization that
does what MAAWG does?
For largest I'd have to *know* that there's nothing else,
and that is not the case, e.g., I can't say what ECO does,
what folks in AP-regions do, and if they
On 7 October 2011 11:36, t.petch wrote:
No thousands of .gif to spend ages downloading, no Megabytes of XML
that take half an hour to process, no https that locks up the
workstation more often than not, no need for a user manual to
explain how to do what; just a simple, self-evident
On 5 October 2011 18:28, Alessandro Vesely wrote:
Hi,
maybe also s/Spam/spam/, since we're at it
I vaguely recall that Spam vs. spam used to be an intentional
difference in Usenet *.abuse.* newsgroups: One variant was for
SPiced hAM, and the other form was for UBE (unsolicited bulk
e-mail) or
On 4 October 2011 16:17, Barry Leiba wrote:
I suggest using document instead of codify as this is not
being standardized.
That's a sensible change.
[Insert DEnglish disclaimer:] For document I read we say so, for
codify I read we say so, and we mean it. While this memo is no
standard, it
Hi, unlike the recent IPv6 delspam/delinsupdate/ins Last Call this
draft makes sense. Admittedly I didn't get the Martians joke, but I guess
it is related to bogons (the latter is clear and also explained).
In essence the draft repeats what BCP 153 (RFC 5735) already said, should it
be added to
On 26 September 2011 16:07, George, Wes wrote:
I’m willing to write a draft about it if there are people willing
to support it, but I only have so many windmills that I can tilt at
per cycle, so I’d like to hear support either privately or publicly
before I undertake it.
Maybe the IETF could
On 22 September 2011 20:02, Michael StJohns wrote:
I actually think that delegating this to a co-chair or executive
vice chair would work. The similar military model is
commander/executive officer where the commander (chair) is
responsible for strategic thinking and the XO (co-chair) is
On 15 September 2011 20:39, Scott O Bradner wrote:
as Keith points out - a round of this type of effort was
undertaken by the newtrk working group a while back
About five years back, IIRC, and with some limiting parameters.
I think this clean up was brilliant, and a new round with new
On 2 September 2011 21:38, Roy T. Fielding wrote:
[http-bis]
OWS = *( HTAB / SP / obs-fold )
; optional whitespace
obs-fold = CRLF ( HTAB / SP )
; obsolete line folding
Clearer. JFTR, this is still avoid *any* folding, and not
On 2 September 2011 22:20, John C Klensin wrote:
I simply don't know how those who are not speaking up feel
https://profiles.google.com/103449397114700758824/posts/1KALM7oLKzi
___
Ietf mailing list
Ietf@ietf.org
On 2 September 2011 23:15, Roy T. Fielding wrote:
this is still avoid *any* folding, and not avoid more
than one folding.
That is the intention. There is no reason to fold in HTTP
outside of the message/http media type.
As a result you get an intentional difference from obs-FWS
in
On 30 August 2011 10:05, Eliot Lear wrote:
There are literally thousands of documents (not only RFCs, also
W3C standards, etc.) with normative references to RFC 2119 (sic!)
instead of BCP 14, and I see no compelling reason to render these
references as historic.
On the basis of this logic
On 30 August 2011 11:14, Mykyta Yevstifeyev wrote:
I would rather object to making RFC 2119 Historic; I remember RFC
2026 discusses such case (probably Section 6.3, which is also
applicable to BCPs). So, the following change is necessary:
Abstract and Introduction (similar text). OLD: If
On 2 September 2011 01:04, Adam Novak wrote:
Who is the appropriate net monkey to handle this?
abuse@ietf works to create a ticket, but IIRC somebody
did that already using a similar address. JFTR, I'd
prefer it if the IAOC doesn't waste money for a new
certificate, and the IETF simply starts
On 29 August 2011 23:36, Peter Saint-Andre wrote:
staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
long enough, I finally decided to submit an I-D that is intended to
obsolete RFC 2119.
There are literally thousands of documents (not only RFCs, also W3C
standards, etc.) with
On 25 August 2011 12:24, Stephane Bortzmeyer wrote:
Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905,
etc), this questionnaire may be of interest for some persons
Thanks for info.
MJD 55798.740729 URL:http://tycho.usno.navy.mil/cgi-bin/daterdnm.sh
-Frank
Hi, a clear definition of same origin on standards track is a good thing.
Maybe some details could be improved:
1 - OWS, maybe I miss the point, but that is apparently the same as LWSP
with an additional SHOULD to produce only a single SP. If that is the
case just saying LWSP would be
Nothing is wrong in BCP 104, it needs no updated by moving the definition
of the term version support from one of its sections to another section.
-Frank
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Am 2011-08-23 01:03, schrieb Brian E Carpenter:
Nothing is wrong in BCP 104, it needs no updated by moving the definition
of the term version support from one of its sections to another section.
But there *is* something wrong with it - it makes IPv6 sound
like an optional add-on to basic IP
On 19 August 2011 23:42, SM wrote:
RFC 5735 covers Special Use IPv4 Addresses.
BTW, some days ago the errata system informed me that a rather old
nit about class E in RFC 3330 made it to held for document update,
but I think RFC 5735 already did that, cf. RFC 3330 eid 1436.
The I-D discussed
On 9 August 2011 14:53, Glen Zorn wrote:
A reasonable place to put this rule (if you wanted to make it a rule)
might have been RFC 5741 but it doesn't seem to be there.
If you insist on it RFC 5741 (thanks, I didn't know it) has a reference
to http://www.rfc-editor.org/styleguide.html.
The IESG wrote:
the approval of this errata would mark an RFC as obsoleted,
the IESG solicits final comments on this errata approval.
This fix helps with the 2616bis effort, please approve it.
Frank
___
Ietf mailing list
Ietf@ietf.org
[EMAIL PROTECTED] wrote:
Is www.my.domain.again.my.domain.com a valid URL on INTERNET?
It's a valid relative URL, but I think that's not what you want
to know...
I know that http://my.domain.again.my.domain.com; can be a
valid INTERNET DNS address
...the other way around it makes sense:
Julian Reschke wrote:
I'm not saying [X]HTML RFCs are an inherently bad idea, just that
they're not as simple to get right as it might seem.
That's true, but I would expect *less* discussions as compared to
just using PDF (for everything).
For the now dead IONs the restriction was roughly
Russ Housley wrote:
http://www.rfc-editor.org/rfc/rfc97.pdf
Yes, that was a famous case for friends of RFC 5198 :-)
I think somebody had a printed copy and scanned it to
fill a gap in the repository at least for PDF.
Now looking at it again, the last page was apparently
never ASCII. Or it
Paul Hoffman wrote:
From the draft, the problem to be solved is:
Documents in the RFC series normally use only plain-text ASCII
characters and a fixed-width font. However, there is sometimes a
need to supplement the ASCII text with graphics or picture images.
ACK. Please note the
Paul Hoffman wrote:
It has to be tuned for the or more part of one or more.
I can't fully parse your meaning, but I think I disagree.
Yes, I also think we disagree. I prefer one file and URL per
figure, avoiding all questions of TARs / ZIPs / JARs / TGZs
to bundle them.
The RFC Editor,
John C Klensin wrote:
My hope is that we can discuss and figure out whether
the community likes and will accept the general idea.
What *is* the general idea ? If it's attaching one
or more figures / images to an RFC I'm fine with it.
Technical detail, for some years we could still stay
Julian Reschke wrote:
if you feel that 8+3 is a limit we need to consider,
what's your opinion on the naming convention for
internet drafts?
My knowledge about old CD-ROM file system is limited
to works for me, and I didn't boot a DOS partition
for years (well, once some months ago, but it
John C Klensin wrote:
PDF/A is considered stable by the archival / depository
librarians, whose traditional criterion for stability
involves a considerably longer timeframe than even the IETF.
Yes. And clearly we can't pick DejaVu, but when it goes
to archival formats without fonts DejaVu is
Julian Reschke wrote:
I've been writing CD-ROM drivers (both low level
and filesystems) in a previous live.
Sounds like fun. The one time I needed to write an
ersatz-file system I got away with flat CP/M style.
Looking around in the mounted CD (Unicode 5.0) all
is fine on my platform, long
John C Klensin wrote:
(i) A text file and maybe xml or nroff that the RFC
Editor is willing to edit/process.
Yes, that is as it is today. I'd be opposed to *any*
changes without an ACK by Henrik for the IETF Tools,
and by Julian for his XSLT magic. And of course Bill
and Marshall, if major
Eric Gray wrote:
The issue I have with either formulation is that BCP 32
currently means RFC 2606 or its successors - hence either
formulation is redundant.
+1 The ID-checklist can reference RFC 2606, and updating
it to 2606bis later is no obstacle. That is no general
recipe: For an RFC
Somebody claiming to be Rubin Rose wrote:
Any review, retransmission, dissemination, or other use of
this information, or taking of any action in reliance upon
it by persons or entities other than the intended recipient
is prohibited.
Further PDFs or other communications claiming to be mail
Brian E Carpenter wrote:
How about adding some weasel words, or even simply making the
attribution requirement a should?
I tend to forget the details, but IIRC we have a SHOULD for an
attribution elsewhere (not in the part about code). If that is
very clear folks might arrive at the
Russ Housley wrote:
I do not think that an Internet-Draft is needed.
The source is already a variant of xml2rfc input, from
there it's easy to arrive at plain text output for the
ordinary diff tools.
Adding version numbers for archiving working with the
diff tool could be as simple as use
Dave Crocker wrote:
This semantic distinction between upper and lower case that
folks keep making is not supported by RFC 2119.
As far as I'm concerned it is perfectly supported by RFC 2119:
The capitalized forms of the keywords have the defined meaning.
Other forms can have a different
Bert Wijnen wrote:
I believe that the ID-Checklist also helped Henrik write the
id-nits tool that will do a check for most of the checlist
items that can (reasonably) be checked by software
[...]
FWIW I consider your checklist as very helpful especially for
new authors, for all the reasons
Lisa Dusseault wrote:
given those caveats and the lack of an official IESG or IETF
position on this
Dunno about the IESG, but I thought the IETF position is what
BCP 115 http://tools.ietf.org/html/rfc4395#section-2.1 says:
2.1 Demonstratable, New, Long-Lived Utility [...] New URI
schemes
Tschofenig, Hannes wrote:
Like with many other areas, you ask 5 persons and get 7 opinions.
How should a working group soliciting advice make an informed
decisions?
If they got opinions their decision could be an informed guess.
In the case of the one to four held* schemes there was one URI
Iljitsch van Beijnum wrote:
Now that we have audio for all sessions (although sometimes the
quality is far from ideal) is it really necessary to repeat
everything that's being said in jabber?
I think the jabber scribe function should be reduced to announcing
new speakers and giving some
Iljitsch van Beijnum wrote:
Maybe Marshall's idea of having two different rooms makes sense.
Dunno, I tried that once in an SPF debate, one room had a public
log, the other was off the record, and it was rather confusing.
For participants (remote or physically elsewhere) it could be
also
Paul Hoffman wrote:
mostly written by Carolyn Duffy Marsan.
In Germany it's often Monika Emmert.
[John Morris wrote]
| My 2 cents
Euro Cents, at least. Accredited journalists and other
proposals for another millennium sounded like Spanish
inquisition, reloaded. The number of folks
Alexey Melnikov wrote:
nothing prevents the final SMTP server from passing commands
to the LMTP server, before replying to the SMTP client.
Thanks for info, I wasn't aware of that possibility. Maybe
it is unnecessary to have the LMTP reference as normative,
but based on your info I agree that
[EMAIL PROTECTED] wrote:
you appears to be complaining that the definition given
in this RFC in fact agrees with yours, perhaps modulo
emphasizing that the intent is to hurt the person whose
address is forged.
Another attempt: Joe Jobs are about hurting an alleged
sender, not about
[EMAIL PROTECTED] wrote:
I certainly have no problem if the consensus changes during
last call to agree with me ;-)
Points where we disagree are more interesting :-) There were
various points where we agreed on this could/should be tuned.
Frank
'Sieve Email Filtering: Reject and Extended Reject Extensions '
draft-ietf-sieve-refuse-reject-07.txt as a Proposed Standard
IMO this draft is _not_ ready for publication on standards track.
The Joe Job in the abstract is a deviation from current usage:
Forging plausible return-paths (to
[EMAIL PROTECTED] wrote:
[Joe Job]
This is the original meaning of the term - you can find the
history behind the term in the Wikipedia entry.
Yes, I recall it, about six years ago, when spammers figured
out that they can actually abuse any plausible return-path.
You are correct to say
The IESG wrote:
'Sieve Email Filtering: Reject and Extended Reject Extensions '
draft-ietf-sieve-refuse-reject-07.txt as a Proposed Standard
The draft wants to update RFC 3028, but this RFC was obsoleted
by RFC 5228. Good riddance wrt 'reject', reviving this CANSPAM
recipe appears to be a
Eric Rescorla wrote:
Missing drafts
[...]
draft-ietf-eai-smtpext-11.txt (wg=eai)
draft-ietf-eai-utf8headers-09.txt (wg=eai)
[...]
Corrected dafts
[...]
draft-ietf-eai-downgrade-07.txt -
draft-ietf-eai-downgrade-08.txt (wg=eai)
draft-ietf-eai-imap-utf8-02.txt -
Ray Pelletier wrote:
Until 7f that all sounds good, but I'm not sure about 7f:
ADD - For the avoidance of doubt, each Contributor to the
IETF Standards Process licenses each Contribution that he
or she makes as part of the IETF Standards Process to the
IETF Trust pursuant to the provisions
John C Klensin wrote:
Better text is welcome if we can agree on the principle. It
may also be that, if we are going to permit addresses, some
words in the Checklist about preferences for IPv4, IPv6, or
parallel examples would be in order.
The principle should be stay away from IP literals
IETF Chair wrote:
http://www.ietf.org/Draft-ID-Checklist.html
Nits:
(1) Archive older versions in a plain text format as for
I-Ds (for use with various IETF tools working on I-Ds)
(2) s/2434/5226/
(3) s/2780/2780 + 5237/
(4) I-D.bellovin expired months ago with three DISCUSSes,
Bill McQuillan wrote:
I wonder if it would make it easier to use example DNS
names if, in addition to the verbose and clumsy: *.example,
IMHO, we reserved gTLDs like *.foo, *.bar, *.bat,
*.baz, as well as the one used quite frequently on this
list lately: *.tld, for use as example DNS
Pete Resnick wrote:
The document says:
If ABNF is used, you MUST include a normative reference to RFC 4234.
To quote two fine radio personalities here in the states, this one
seems boogus. Yes, any I-D that uses ABNF must include a
normative reference to RFC 4234
The ID-Checklist
IESG Secretary wrote:
This is a response to that appeal.
[...]
The IESG came to consensus that the use of non-example domain
names should not prevent publication of RFC2821bis, even though
the IESG finds this practice can cause harm.
Good enough, hopefully the discussed examples are updated
Bill Manning wrote:
http://www.icann.org/committees/security/sac032.pdf
is illustrative.
| entrusted agents should provide opt-out mechanisms that
| allows clients to receive the original DNS answers to
| their queries.
[...]
| Organizations that rely on accurate NXDomain reporting
| for
John C Klensin wrote:
For years, we managed to dodge that problem with conventional
subdomains (e.g., nic.example.), but we have not, to my knowledge,
ever promoted those uses via, e.g., a BCP that strongly recommends
them (unlike the email case, where RFC2142 does just that).
I'd be happy
John Levine wrote:
The cost to get a domain from ICANN under the new rules is
estimated to be about $100,000. Don't you think we can assume
that people who are laying out that kind of money are big boys
and girls who will do adequate due diligence?
How could their money help them to find
John C Klensin wrote:
http://[10.0.0.6]/ anyone?
My bastard browser from hell eats http://[208.77.188.166]/
It's certainly no STD 66 URL. But it won't surprise me if
the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis,
(etc. ad nauseam) effort styling itself as HTML5 decrees
that this
John C Klensin wrote:
http://[10.0.0.6]/ anyone?
My bastard browser from hell eats http://[208.77.188.166]/
It's certainly no STD 66 URL. But it won't surprise me if
the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis,
(etc. ad nauseam) effort styling itself as HTML5 decrees
that this
Mark Andrews wrote:
The Internet went to multi-label hostnames ~20 years ago.
As noted in RFC 2821 as one dot required syntax, also
mentioned in RFC 3696. Recently *overruled* by 2821bis.
No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]
to work reliably.
Certainly not
James Seng wrote:
if the character is defined more broadly to cover U-label
character, then I would have strong objections.
+1 And fortunately it's not our job to figure out what a term
like IDN ccTLD actually means, where that might be important.
I remember it is a standing tradition that
Mark Andrews wrote:
The Internet went to multi-label hostnames ~20 years ago.
As noted in RFC 2821 as one dot required syntax, also
mentioned in RFC 3696. Recently *overruled* by 2821bis.
No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]
to work reliably.
Certainly not
Simon Josefsson wrote:
How about an IETF operations mailing list? There is the tools
mailing list, but I don't think this kind of operational discussions
belong there. People interested in the operations of various IETF
servers could join that mailing list. The list might even be an
David Conrad wrote:
TLDs starting with a number but containing non-numerics would be
disallowed (I'm reminded of the fun long ago with 3com.com)?
Yes, killing the 0x 1*HEXDIG oddity. I wasn't thrilled when
my browser supported the http://0xd0.0x4d.0xbc.0xa6/ feature.
Frank
John C Klensin wrote:
rules like this are ultimately useless unless ICANN agrees to
them, presumably via the gNSO, one at a time, and via a PDP
process.
As long as PDP translates into individual Last Call comments
for a future draft-ietf-idnabis-952bis that's fine.
Nothing rush like
David Conrad wrote:
Would there be the downside to this?
Hi, that's already planned, I'm lazy, here's a copy:
| that will be done in an draft-ietf-idnabis-952bis to nail the
| two RFC 1123 toplabel errata, see the A-label thread(s)
| on the IDNAbis list:
|
|
Marshall Eubanks wrote:
.internal
What's that supposed to be good for ? At the moment the
2606bis draft proposes to create a IANA registry of new
reserved TLDs, populated with TLDs surviving IETF review.
maybe translations of .test
Covered, a copy of the 11 IDN test TLDs created by ICANN
Dave Cridland wrote:
A SHOULD X unless Y essentially means SHOULD (X or Y)
I'd read it as do X, but if you have a very good excuse
not doing X might do. One known very good excuse is Y.
OTOH for a MUST X I'd want no qualifiers, MUST means an
attempt to do not X can cause havoc.
This is
Debbie Garside wrote:
I and a few others thought a BCP was worth something. Apparently not.
Please don't panic, nobody said that RFC 2606 or 4646 are worthless.
This discussion is mainly about some bugs in the DISCUSS protocol,
and the somewhat unclear status of the IDNITS specification.
Stephane Bortzmeyer wrote:
my message is about the examples RFC such as 2606,
3330, 3849 or 4735.
I don't see a plausible way to reference RFC 4735
in 2606bis. The examples zoo should get its own
section in Brian's next IETF marauders map - adding
TLH example in the Usefor RFC for NetNews.
Robert Elz wrote:
The issue is why the IESG is ignoring the demonstrated
will of the IETF.
Figuring out what the demonstrated will of the IETF is
is the job of the IESG, and in the case of an individual
submission such as 2821bis it can be rather tricky.
Somebody *deciding* that using
Robert Elz wrote:
[general procedural considerations:]
It can be tricky in any case, I don't really think individual
submissions are that different - in either case, there's a
last call, and the results need to be evaluated.
A WG is an additional layer to sort out conflicts, with Chairs
John C Klensin wrote:
hypothesize that, at some point, an RFC 2606bis might be created
(and go through the consensus process to BCP) that offers special
reserved names for newsgroups or mailing lists as well as domain
names
JFTR, with respect to newsgroups that is already specified in
Brian E Carpenter wrote:
That's my opinion; I'm not asserting that it's an IETF
consensus or that it necessarily applies to 2821bis.
+1
Some things I'd consider:
RFC 821 used foo.arpa and similar examples, and it won't
surprise me if the author knew precisely why this can
never have any
Hi, another 2606bis draft is available at the usual places:
http://tools.ietf.org/html/draft-ellermann-idnabis-test-tlds
In -02 I've proposed the general list for discussions, the
SMTP and IDNAbis lists are to varying degrees unsuited. :-)
Frank
___
Chad Giffin wrote:
Could any of you please provide me with a URL to access this
document using HTTP and/or email me this particular document?
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?url=http://www.ietf.org/ietf/1id-guidelines.txt
http://www.ietf.org/ietf/1id-guidelines.txt
Paul Hoffman wrote:
5. Standards change: When a document has been approved
(via Protocol Action Notice or equivalent) that updates
or obsoletes an existing Standards Track or BCP
document, an erratum entry may be added that points to
the action notice and the approved Internet-Draft. This
SM wrote:
Quoting RFC 2555:
Hopefully we'll get a next year :-)
The Tao has an air of formality in some places.
Mostly limited to appendix B, though.
In Section 1:
An Internet Draft's life cycle begins when the author(s)
submit the document as an individual submission
Suresh Krishnan wrote:
We would really appreciate
[...]
In the spirit of your draft: s /one an author/once an author/ ;-)
As the draft says, the main thing is to get any reviews at all:
A negative review means that somebody bothered to read it, and
to note whatever attracted their attention.
Stephane Bortzmeyer wrote:
ISO standards are referenced by an ISO-specific syntax
(such as ISO 3297:2007, which does not seem very
different from the syntax RFC 5141).
FWIW ISO created an URN recently, see urn:ietf:rfc:5141
or http://purl.net/net/rfc/5141
or
Tom Petch wrote:
I note that this will also give us a URN (RFC3044).
What's the point of another URN in addition to urn:ietf:rfc:2648 ?
The ISSN idea is fine if this gets RFCs cataloged in places where
they are not available at the moment.
For the info-handles and DOI ideas I don't
Eric Burger quoted:
On May 4, 2008, at 5:12 AM, Eric Rescorla wrote:
Examining the diff, it does not appear to me that
any of my comments from my previous review.
If the draft still talks about Message-IDs which are
something else I have to say +1:
1 - 100 of 510 matches
Mail list logo
