Re: update on draft-meadors-ediint-features-header and IANA review requested

[Graham Klyne <[e-mail]>]

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:[e-mail]] Sent: Saturday, June 12, 
>> 2010 2:17 AM
>> To: Kyle Meadors
>> Cc: 'Nevil Brownlee'; [e-mail]; '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
>>>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>> 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.
>>>
>>> * * * * * * * * * * * * * * * * * * * * * * * *
>>>