[auth48] Final question - AUTH48: RFC-to-be 9277 <draft-ietf-cbor-file-magic-12> for your review

[Sandy Ginoza <[e-mail]>]

Hi Carsten, Michael, 

Actually, we see that the XML uses <contact> as follows:

   Note that no tag numbers are assigned for Content-Format numbers in                   
   the range 65025 <contact fullname="≤"/> ct <contact fullname="≤"/> 65535.

This is inappropriate use of the <contact> element.  I understand it’s not ideal, but may we either switch this to <artwork> or go with ASCII only? 

Example of artwork: 

   Note that no tag numbers are assigned for Content-Format numbers in
   the following range:

   <artwork>65025 ≤ ct ≤ 65535</artwork>

You can see the output here: 

https://www.rfc-editor.org/authors/sandy.html#appendix-B
https://www.rfc-editor.org/authors/sandy.txt
https://www.rfc-editor.org/authors/sandy.pdf


Otherwise, perhaps we use ASCII only (i.e., 65025 <= ct <= 65535) until non-ASCII characters can be used more liberally. 


Any other ideas? 

Thanks,
Sandy 


> On Aug 30, 2022, at 3:40 PM, Sandy Ginoza <[e-mail]> wrote:
> 
> Hi Carsten,
> 
> Thanks for the nudge — the document has been updated and is now ready for publication.  Apologies for the delay!
> 
> RFC Editor/sg
> 
>> On Aug 30, 2022, at 7:54 AM, Carsten Bormann <[e-mail]> wrote:
>> 
>> On 2022-08-19, at 22:22, Carsten Bormann <[e-mail]> wrote:
>>> 
>>> 
>>> OLD:
>>> encoded.  For instance, an Android APK (as used to transfer and store
>>> an application) may be identified as a ZIP file.  Additionally, both
>>> NEW:
>>> encoded.  For instance, an Android Package Kit APK (as used to transfer and store
>>> an application) may be identified as a ZIP file.  Additionally, both
>> 
>> Is this something the RFC editor wants to pick up?
>> It seems to me we are done here after this change.
>> 
>> Grüße, Carsten
>> 
>