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

Sandy Ginoza <sginoza@amsl.com> Fri, 05 April 2024 18:48 UTC

From: Sandy Ginoza <sginoza@amsl.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_97BA629E-7208-437A-8CFD-45E79DCFCDE9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 05 Apr 2024 11:47:25 -0700
References: <84f1813c-8bf6-4206-a5b3-349fc6560ed1@app.fastmail.com>
Cc: Karen Moore <kmoore@amsl.com>
To: rpat <rpat@rfc-editor.org>
Message-Id: <FC5E05B9-DE2A-4709-8241-EC60A9E7CC39@amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rpat/ilVSJe8hK3OMittLn3qtjF38Gec>
Subject: [rpat] Media types as soucecode for incomplete examples? - Fwd: AUTH48: RFC-to-be 9555 <draft-ietf-calext-jscontact-vcard-13> for your review
Precedence: list

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: 

            <sourcecode type="text/vcard"><![CDATA[                                          
item1.TEL;VALUE=uri:tel:+1-555-555-5555                                                      
]]></sourcecode>

            <sourcecode type="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=40fastmailteam.com@dmarc.ietf.org>
> 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" <kmoore@amsl.com>, "Orie Steele" <orie@transmute.industries>, "Murray S. Kucherawy" <superuser@gmail.com>, "Mario Loffredo" <mario.loffredo@iit.cnr.it>
> Cc: rfc-editor <rfc-editor@rfc-editor.org>, calext-ads@ietf.org, calext-chairs@ietf.org, "Daniel Migault" <mglt.ietf@gmail.com>, auth48archive <auth48archive@rfc-editor.org>
> 
> 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

[rpat] Media types as soucecode for incomplete ex… Sandy Ginoza
Re: [rpat] Media types as soucecode for incomplet… Robert Sparks