Re: [rpat] Media types as soucecode for incomplete examples? - Fwd: AUTH48: RFC-to-be 9555 <draft-ietf-calext-jscontact-vcard-13> for your review

[Robert Sparks <[e-mail]>]

Well, this is essentially the same question that got answered "you can't 
use things that don't follow the definition" when I had to write 
https://datatracker.ietf.org/doc/rfc3420/, but that was long ago and 
maybe mime theory has relaxed in the meantime.

RjS

On 4/5/24 1:47 PM, Sandy Ginoza wrote:
> Hi,
>
> We recently started allowing media types to be listed as sourcecode 
> types.  Do you have an opinion on whether the specific media type 
> should be used for incomplete examples?  For RFC-to-be 9555, we are 
> discussing whether it is more appropriate to use “text/vcard” vs 
> “text/plain” for partial vCard text.  Here are some examples from the 
> document:
>
>           <sourcecodetype="text/vcard"><![CDATA[
> item1.TEL;VALUE=uri:tel:[phone]
> ]]></sourcecode>
>
>             <sourcecodetype="text/vcard"><![CDATA[
> FN;LANGUAGE=EN:John Doe
> TITLE;ALTID=1;LANGUAGE=EN:Boss
> TITLE;ALTID=1;LANGUAGE=fr:Patron
> ]]></sourcecode>
>
> Please see the discussion below.  I think text/plain is a default, but 
> it seemingly provides less information to the user than specifying 
> text/vcard.  Am I understanding this correctly?
>
> RFC-to-be is currently in AUTH48.  Your an view the files here:
> https://www.rfc-editor.org/authors/rfc9555.html
> https://www.rfc-editor.org/authors/rfc9555.xml
>
> Thanks,
> Sandy
>
>
>
>> Begin forwarded message:
>>
>> *From: *Robert Stepanek <rsto=[e-mail]>
>> *Subject: **Re: AUTH48: RFC-to-be 9555 
>> <draft-ietf-calext-jscontact-vcard-13> for your review*
>> *Date: *April 5, 2024 at 2:10:09 AM PDT
>> *To: *"Karen Moore" <[e-mail]>, "Orie Steele" 
>> <[e-mail]>, "Murray S. Kucherawy" 
>> <[e-mail]>, "Mario Loffredo" <[e-mail]>
>> *Cc: *rfc-editor <[e-mail]>, [e-mail], 
>> [e-mail], "Daniel Migault" <[e-mail]>, 
>> auth48archive <[e-mail]>
>>
>> Hi Karen, Orie,
>>
>> On Thu, Apr 4, 2024, at 11:29 PM, Karen Moore wrote:
>>> > [OS] Thanks for making this change, in case "text/vcard" is 
>>> rejected (for some tooling reason) "text/plain" would also work... 
>>> in fact it may be more appropriate if the source code is not a fully 
>>> valid vcard in text serialization... Is it valid?
>>>
>
> [snip]
>
>> The examples contain only partial vCard text, so strictly speaking 
>> "text/vcard" is not appropriate. If that is an issue, "text/plain" is 
>> equally fine.
>>
>>>
>>> > NEW:
>>> >    The PREF parameter (Section 5.3 of [RFC6350]) converts to the pref
>>> >    property of the derived JSContact object.
>>>
>>>
>>> Please consider if any updates are needed to this similar sentence 
>>> that follows in Section 2.3.18:
>>>
>>>   The PROP-ID parameter (Section 4.7 of [RFC9554]) converts to the Id-
>>>    typed key of the JSContact object, to which the vCard property having
>>>    this parameter converts.
>>
>> I think Orie's suggestion for the PREF parameter is great, and I 
>> kindly ask you to apply it also to the PROP-ID definition.
>>
>> Thanks,
>> Robert
>
>