Re: [usefor] [Technical Errata Reported] RFC5537 (4468)

Hi all,

It seems that the current thread is not archived in
   https://www.ietf.org/mailman/listinfo/usefor

Would it be possible to update the old <ietf-usefor@imc.org> address 
used to the current <usefor@ietf.org> address?  (And if possible, update 
all imc.org addresses to ietf.org in the contacts of the RFC Editor.)
Maybe it is the reason of the lack of these mails in the archives. 
Another possibility would be that the list is in the Cc: recipients 
instead of To:.

Thanks!

-- 
Julien ÉLIE

« – Essayons d'interroger ce garde habilement sans éveiller ses
     soupçons…
   – Hep ! Où est enfermé Assurancetourix ? » (Astérix)

Le 15/10/2015 08:40, Harald Alvestrand a écrit :
> On 10/14/2015 11:04 PM, Barry Leiba wrote:
>>>> I'm fine with marking the erratum REJECTED.
>>>> When doing that, could you please add Russ's comment so as to give more
>>>> context for people that will eventually process that erratum in a future
>>>> revision of the RFC?  (If of course Russ and Harald are OK with that.)
>>>>
>>> I am not familiar with what can and cannot be done with an erratum, but I
>>> think it is important that a permanent record of this problem is placed
>>> somewhere so that, if ever we proceed to Draft Standard (unlikely, perhaps,
>>> but nevertheless possible) then the matter will be picked up and the
>>> situation regularized.
>> Indeed.  I plan to make it "held for document update".
>>
>> Barry
> I think the limit to an erratum is that an erratum can't override a WG
> decision.
> "Held for document update" is fine for "someone needs to look at this
> carefully if they are ever charged with updating the spec".
>
> In this case, my memory says that we deliberately chose to look away
> from what existing implementations do and instead say how things should
> function if people were allocating the pieces of functionality between
> the components of the ecosystem that we were imagining in the way they
> were imagined - in which the posting agent was under the user's control,
> and could sensibly correct the user's mistakes, while the injecting
> agent was under the service provider's control, and should insist on
> things being correct before it got there. Real implementations don't
> line up that neatly - the spec never says what the protocol between a
> posting agent and an injecting agent is.
>
> This may have been the wrong decision in retrospect, but I think the
> decision got made that way.