Eric Rescorla writes:
>In my experience, there are four major scenarios for diagnosing this kind of
>failure. Under the assumption that you control one end, the other end can be:
>
>1. A live endpoint.
>2. A testing endpoint someone has put up.
>3. An endpoint that someone is
Salz, Rich writes:
>>format, which I assume just means adding a free-form text field to the
>>existing alerts.
>
>Doesn't it have to be tagged with language and codeset these days?
Possibly, if you consider being able to say "Invalid length encoding in
Hi,
The published -11 text is even better than the proposal below.
Thanks
Brian Carpenter
On 23/03/2018 08:10, Brian E Carpenter wrote:
> That looks good to me. I think it will help implementers.
>
> Thanks
>Brian Carpenter
>
> On 22/03/2018 21:41, Xavi Vilajosana Guillen wrote:
>>
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please wait for direction from your document
shepherd or AD before posting a new version of the draft. For more
information,
Thinking through this some more, I'm skeptical that this is going to be
that useful as a debugging-only feature.
In my experience, there are four major scenarios for diagnosing this kind
of failure. Under the assumption that you control one end, the other end
can be:
1. A live endpoint.
2. A
>format, which I assume just means adding a free-form text field to the
existing alerts.
Doesn't it have to be tagged with language and codeset these days? I think
we're past USASCII ...
___
Gen-art mailing list
Gen-art@ietf.org