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

[Sandy Ginoza <[e-mail]>]

All,

Thank you for your quick replies!  We have updated the doc and will continue with publication at this time.

Thanks,
Sandy 


> On Aug 30, 2022, at 5:41 PM, John R. Levine <[e-mail]> wrote:
> 
>> The <artwork workaround works for me.
>> The <contact approach is working around an inappropriate enforcement in xml2rfc of a senseless rule
> 
> While I agree that someday we will relax the RFC 7997 rules for what's allowed in running text, we're not going to do it one code point at a time and we haven't done it today.  If you suggest to the RSWG expanding the allowable character set as a work item, I'll support it.
> 
>> Anyway, for expediency, let’s go with <artwork.
> 
> Seems reasonable.
> 
> R's,
> John
> 
> 
> 
>> 
>> Sent from mobile, sorry for terse
>> 
>>> On 31. Aug 2022, at 01:49, Sandy Ginoza <[e-mail]> wrote:
>>> 
>>> 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
>>>>> 
>>>> 
>>> 
>> 
> 
> Regards,
> John Levine, [e-mail], Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly