[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Evaluation: draft-klyne-msghdr-registry - Registrationproced ures for message header fields to BCP





--On torsdag, juni 12, 2003 03:05:36 -0500 "Peterson, Jon" <jon.peterson@neustar.biz> wrote:


                    Yes    No-Objection  Discuss *  Abstain

Jon Peterson        [   ]     [   ]       [ x ]      [   ]

The largest issue I have with this document is I'm unsure what degree of
compliance is anticipated. Is this document a mandate that all existing
protocols must register their headers in the Permanent Message Field
Registry? Or only all specifications published from this point forward?
What about protocols that already have existing IANA registries for
headers - are they expected/required to publish twice, or to deprecate
their existing registries?
no such registries exist, AFAIK. Possibly SIP has one?

The document says that IANA should pre-provision the Permanent Message
Field Registry with values from draft-klyne-hdrreg-mail and
draft-nottingham-hdrreg-http. Both are expired since 2002 (though the
latter, at least, is still in the I-D repository). I suppose these should
have gone forward with this document as a bundle? I also wonder, though,
that given the extensive list of RFCs in section 2.2, examples from mail
and http alone would have been investigated here.
finding some energy to do the legwork is probably the problem.

I think this document is a bit dated. For one thing, the listings of RFCs
in 2.2 only go up to around RFC3000; consequently, it lists some obsolete
specifications (like RFC2543 instead of RFC3261) and probably omits some
newer specifications that should fall under its yoke.
Right. It's been "obvious" for 5 years - again, energy's been the problem, I think.

From a reviewer:

The IANA procedures for SIP header registrations purposefully preclude
registration of experimental headers (this was at the request of iesg).
That seems at odds with the provisional mechanism in this draft. I don't
know how to reconcile these two views.
this is something the IESG has to come to a conclusion about...