to end of DATA command)
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Reporting-MTA: dns; mailout.west.internal
X-Postfix-Queue-ID: 36E2ED60
X-Postfix-Sender: rfc822; dcrocker@bbiw.net
Arrival-Date: Wed, 10 Feb 2021 08:30:34 -0500 (EST)
Final-Recipient: rfc822; worley@ariadne.com
Original
details, see Section 3.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
On 1/30/2021 3:13 PM, Ned Freed wrote:
Finally, I think a couple of word choices could be better. So how about:
Having seen no objections, I've replaced the draft's existing text with
Ned's proposed alternative.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 1/31/2021 2:16 PM, Dale R. Worley wrote:
Dave Crocker writes:
On 1/27/2021 6:32 PM, Dale Worley via Datatracker wrote:
The emoji(s) express a recipient's summary reaction to the specific
message referenced by the accompanying In-Reply-To header field.
[Mail-Fmt
On 1/28/2021 12:21 AM, Kjetil Torgrim Homme wrote:
On Wed, 2021-01-27 at 19:35 -0800, Dave Crocker wrote:
To the extent that your intent is to say that a) this is a subset of
UTF-8, and b) multiple bytes can be used, I think that's built into the
definition of emoji-sequence.
In fact, I had
t;DNS nodes names" doesn't quite scan for me. "DNS node names"
perhaps?
Section 4.2: s/simply/simplify/?
Section 5: s/in the of/in the/?
done.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@iet
Henrik,
Thanks for the quick followup...
On 9/26/2018 1:08 PM, Henrik Levkowetz wrote:
I think xml2rfc does the right thing. The quotes are provided by
you, the author, not the processor, and you've enclosed the element
completely in the quotes:
yeah, sorry. played with the combinatorials
On 9/24/2018 6:16 AM, Dave Crocker wrote:
+ Those registered by IANA in the "Service Name and Transport
Protocol Port Number Registry [RFC6335]"
Move the end quote after Registry.
ok. Good catch.
Interesting. Just discovered that this probably qualifie
f: Normative reference to an Informational RFC: RFC 7553
That document is a specification. This document modifies it. No matter
it's standards track status, it is a normative reference to this document.
-- Obsolete informational reference (is this intentional?): RFC 3921
(Obsoleted by RFC
: It defines the topic and it
says the IETF considers the topic important. It calls for practices,
but doesn't -- and shouldn't -- define them.
The job of providing substantive details about IETF practices associated
with the topic will come later.
d/
--
Dave Crocker
Brandenburg InternetWorking
justify encourages
this latter expectations. the view that we have far more community
clue about this topic than we currently have.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org
of trying to be practical about being practical, I'll suggest
that any IESG blocks based on a concern about pervasive monitoring needs
to reflect a consensus view of the IESG, not just the concern of a
single AD
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
have the purpose of
including extensive annotations for possible later use, attempting to
anticipate or hypothesize later editing efforts, to revise the base
document.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing
of responsibilities to individuals, rather than aggregations
of them.
All very abstract, I admit. From the vantage point of some decades,
even quaint.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https
with a couple of usage examples, would go a long way towards
showing how this update helps in practical ways.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
-downgrade? That document does contain
examples and an explanation of that particular use case.
I thought Ned's goal was -- quite reasonably, IMO -- to not be dependent
upon EAI for this general-purpose enhancement.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
with the current text is that it says 'what'
motivated the change, but not how it is useful for the intended class of
uses. The reader is left entirely to guess.
Self-actualization among the inadequately-informed invites fantasy more
than it invites utility.
d/
--
Dave Crocker
Brandenburg
, including a cross reference of the
type I prefer to avoid:
1. State that this removes a restriction that was never essential.
2. State that the timing of this removal is to accomodate EAI and
for its use of the now-available features, see [RFC].
d/
--
Dave Crocker
Brandenburg
in
isolated 'background' or 'history' discussions (and, of course, the
Updates field...)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
the point, possibly the same
language as you just used to explain it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
to provide.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
thanks!
d/
On 1/11/2010 1:49 PM, Suresh Krishnan wrote:
Summary: This draft is ready for publication as Informational RFC.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org
Vijay K. Gurbani wrote:
Major issues: None.
Minor issues: None.
Nits/editorial comments:
1) S3.1
s/VPIM [RFC3801] such as/VPIM [RFC3801], such as/
2) Figure 5, in the legend:
s/bpxes/boxes
cool. thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
of scope for your review, can you summarize the nature of what was *in* scope?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
24 matches
Mail list logo
