Re: update on draft-meadors-ediint-features-header and IANA review requested
Graham Klyne <GK <at> ninebynine.org>
2010-06-14 18:53:14 GMT
Alexey Melnikov wrote:
> Hi Kyle,
>
> Kyle Meadors wrote:
>
>> To confirm, my next step would be to resubmit a new version of this draft
>> but include this section below in the IANA consideration section.
>>
> Yes.
>
>> Question:
>> do I need to specific the protocol as AS2/AS1/AS3 or HTTP/mail?
>>
>> This is a request for a permanent header registration.
If it's a request for permanent registration, I'd be looking for adequate
evidence of IETF consensus - a note from you (Alexey) would suffice.
(Otherwise, I'd recommend registration as provisional until any applicable
last-call process has been completed, with a view to promoting it at that point.)
>> Header field name: EDIINT-Features
>> Applicable protocol: AS2 (RFC 4130), AS1 (RFC 3335), AS3 (RFC 4823)
>>
>>
> I think this should be one or more of "mail", "http" (per RFC 3864):
>
> Applicable protocol:
> Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
> "netnews" (RFC 1036), or cite any other standards-track RFC
> defining the protocol with which the header is intended to be
> used.
Agreed. The comments about use with AS2, etc, would usefully be included in the
"Related information" section of the template.
>> Status: Informational
>> Author/Change controller: IETF
If this is "informational", is it properly under IETF change control? Or is
there an EDIInt consortium or body that can more usefully be cited?
>> Specification document(s): This I-D (will include a URI)
As a process detail, I think the actual registration would then have to take
place during the IANA considerations processing phase of RFC publication? Thus,
I think we need to be clear that there's adequate consensus for a permanent
registration before activating the publication process. That's an IESG call to
make.
>> Related information: None.
#g
--
>> -----Original Message-----
>> From: Graham Klyne [mailto:GK <at> ninebynine.org] Sent: Saturday, June 12,
>> 2010 2:17 AM
>> To: Kyle Meadors
>> Cc: 'Nevil Brownlee'; ietf-ediint <at> imc.org; 'Alexey Melnikov'
>> Subject: Re: update on draft-meadors-ediint-features-header and IANA
>> review
>> requested
>>
>> Dear all,
>>
>> My apologies for the delay in dealing with this.
>>
>> My main comment is that there is no registration template per
>> http://tools.ietf.org/html/rfc3864. Normally, I would expect to see
>> this template included in the IANA considerations section (which, as
>> it stands,
>> isn't really about IANA considerations per se, but a request for
>> expert review - I
>>
>> think there may be a related process issue here which I'll raise
>> separately
>> with Alexey), or submitted separately to IANA per
>> http://tools.ietf.org/html/rfc3864#ref-35
>>
>> For example, it's not clear to me if this is requesting provisional or
>> permanent registration.
>>
>> I also note that the registration procedure is not cited, which would
>> probably be helpful, though I'm not sure that's a requirement.
>>
>> As for the header field itself, I see no problem with it.
>>
>> #g
>> --
>>
>>
>> Kyle Meadors wrote:
>>
>>
>>> Alexey, Nevil,
>>>
>>>
>>>
>>> I have made the changes to the BNF and other comments and re-submit
>>> my I-D.
>>>
>>>
>>>
>>> Graham,
>>>
>>>
>>>
>>> Per conversation with Alexey, I am requesting an IANA expert review
>>> on a registering a new http and email header, EDIINT-Features. The
>>> request is in the I-D listed below. Thank you.
>>>
>>>
>>>
>>> http://datatracker.ietf.org/doc/draft-meadors-ediint-features-header/
>>>
>>>
>>>
>>> Kyle Meadors
>>>
>>> Drummond Group Inc.
>>>
>>> Director of EHR Testing
>>>
>>> Principal, Test Process
>>>
>>> 817-709-1627
>>>
>>> kyle <at> drummondgroup.com <mailto:kyle <at> drummondgroup.com>
>>>
>>>
>>>
>>> Calendar: http://tinyurl.com/KyleMeadors-DGI-Calendar
>>>
>>>
>>>
>>> * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>> CONFIDENTIALITY DISCLAIMER
>>>
>>> This email, including attachments, is confidential and proprietary.
>>> It constitutes exclusive communication solely to the addressee. Any
>>> entity other than the intended addressee is prohibited from use of
>>> this communication for any purpose. This email, including
>>> attachments, may not be distributed, whole or in part.
>>>
>>> * * * * * * * * * * * * * * * * * * * * * * * *
>>>