[rfc-i] rfc-interest Digest, Vol 189, Issue 14

BBMcoll BBMcollections at bell.ca
Wed Jul 22 21:24:20 PDT 2020


Un message en français suivra
Thank you for your email.
A response to your inquiry will be provided as quickly as possible within the next 24 hours, during business hours (Eastern Time).
If this is an urgent matter, please contact our office at 1-866-350-7710.
Thank you for contacting BBM -Bell Business Markets Collections
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Merci de votre courriel.
Nous répondrons à votre demande dans les plus brefs délais à l’intérieur des prochaines 24 heures , durant les heures normales de bureau (heure de l’Est).
Pour toute question urgente, veuillez appeler notre bureau aux 1 866 350-7710.
Merci d’avoir communiqué avec l’équipe Recouvrement de Bell Marchés Affaires.

From: rfc-interest-request at rfc-editor.org
Sent: Thursday, July 23, 2020 12:22 AM
To: rfc-interest at rfc-editor.org
Subject: [EXT]rfc-interest Digest, Vol 189, Issue 14

Send rfc-interest mailing list submissions to
        rfc-interest at rfc-editor.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.rfc-editor.org/mailman/listinfo/rfc-interest
or, via email, send a message with subject or body 'help' to
        rfc-interest-request at rfc-editor.org

You can reach the person managing the list at
        rfc-interest-owner at rfc-editor.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rfc-interest digest..."


Today's Topics:

   1. Re: [xml2rfc] use of sourcecode type (Martin Thomson)
   2. Re: [xml2rfc] use of sourcecode type (John Levine)
   3. Re: [xml2rfc] use of sourcecode type (Martin Thomson)
   4. Re: [xml2rfc] use of sourcecode type (John R Levine)
   5. Re: [xml2rfc] use of sourcecode type (Carsten Bormann)
   6. Re: [xml2rfc] use of sourcecode type (John R Levine)


----------------------------------------------------------------------

Message: 1
Date: Thu, 23 Jul 2020 11:37:35 +1000
From: "Martin Thomson" <mt at lowentropy.net>
To: rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <71455ac8-14b1-45a7-a27f-bdeb50ed1917 at www.fastmail.com>
Content-Type: text/plain;charset=utf-8

In rust documentation, there is a flag for example code that says "this code is invalid".  That is separate from the (implied) type.

I don't see it being necessary to fix the "this is invalid, but it is if you add it to this other thing".  But that might be fixed with an excerpt flag that says "this is an excerpt (from X?) and therefore not valid on its own".

As for IANA maintaining a registry of types, sure.  I had no idea that this was a thing until the tls-syntax tag was added by the editor to one of my drafts.

On Wed, Jul 22, 2020, at 01:10, Carsten Bormann wrote:
> A similar problem is giving examples that are intentionally bad in
> order to demonstrate a kind of error.
>
> I typically tag them with a type that is derived from the one I would
> give for real code, e.g., ?CDDLx? for a bad CDDL example.  I think it
> would be good to agree on some way to indicate this.
>
> A related problem is that often several code blocks combine to one
> valid instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428.
> There is no way to say that Figure 1 and 2 combine into a valid
> instance, and so do Figure 1 and 3, but not any other combination.
>
> And, by the way, those type tags are conventionally lower-cased, but
> this is not made very explicit; you have to infer that from the list in
> Section 2.48.4 of RFC 7991 or the RFC editor?s updated copy of that
> list:
>
> https://www.rfc-editor.org/materials/sourcecode-types.txt
>
> (Ha, this doesn?t even have ?cddl? in it; I?m not sure how this is
> updated and whether there shouldn?t really be an IANA registry for
> these.)
>
> Gr??e, Carsten
>
>
> > On 2020-07-21, at 16:36, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> >
> > I have a question about specification of type in sourcecode elements:
> >
> > In RFC4566bis there are many examples that have fragments of SDP. But they aren't compliant to SDP syntax, since it requires that many things be present - that are intentionally omitted from these examples.
> >
> > Is it valid to tag these with type="SDP"?
> >
> > (In sip we had a similar problem. There is a mime-type message/sip, but we sometimes also return fragments of sip in error messages. We ended up defining a separate message/sipfrag mime-type for this.)
> >
> >      Thanks,
> >      Paul
> >
> > _______________________________________________
> > xml2rfc mailing list
> > xml2rfc at ietf.org
> > https://www.ietf.org/mailman/listinfo/xml2rfc
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>


------------------------------

Message: 2
Date: 22 Jul 2020 22:45:52 -0400
From: "John Levine" <johnl at taugh.com>
To: rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <20200723024552.38FAE1D65AD2 at ary.qy>
Content-Type: text/plain; charset=utf-8

In article <71455ac8-14b1-45a7-a27f-bdeb50ed1917 at www.fastmail.com> you write:
>In rust documentation, there is a flag for example code that says "this code is invalid".  That is
>separate from the (implied) type.
>
>I don't see it being necessary to fix the "this is invalid, but it is if you add it to this other
>thing".  But that might be fixed with an excerpt flag that says "this is an excerpt (from X?) and
>therefore not valid on its own".

If people can come up with a list of conventional code types, we can encourage people to use them.

>As for IANA maintaining a registry of types, sure.  I had no idea that this was a thing until the
>tls-syntax tag was added by the editor to one of my drafts.

Once again, no.  The RSE keeps a list of conventional artwork types, not IANA.  See RFC 7991, sec 2.5.7.

R's,
John


------------------------------

Message: 3
Date: Thu, 23 Jul 2020 13:23:26 +1000
From: "Martin Thomson" <mt at lowentropy.net>
To: "John R Levine" <johnl at taugh.com>, rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <8ea0ca88-15da-4d86-b199-0d99dc7675fe at www.fastmail.com>
Content-Type: text/plain

On Thu, Jul 23, 2020, at 12:45, John Levine wrote:
> Once again, no.  The RSE keeps a list of conventional artwork types,
> not IANA.  See RFC 7991, sec 2.5.7.

We documented this format in an RFC because we thought that interoperability matters.  I don't think that the RSE gets to be above that.


------------------------------

Message: 4
Date: 22 Jul 2020 23:40:46 -0400
From: "John R Levine" <johnl at taugh.com>
To: "Martin Thomson" <mt at lowentropy.net>, rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <6d87c55-6d3-81fb-bf70-8f9a46d76b0 at taugh.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed

> On Thu, Jul 23, 2020, at 12:45, John Levine wrote:
>> Once again, no.  The RSE keeps a list of conventional artwork types,
>> not IANA.  See RFC 7991, sec 2.5.7.
>
> We documented this format in an RFC because we thought that
> interoperability matters.  I don't think that the RSE gets to be above
> that.

That section of RFC 7991 says:

2.5.7.  "type" Attribute

    Specifies the type of the artwork.  The value of this attribute is
    free text with certain values designated as preferred.

    The preferred values for <artwork> types are:

    o  ascii-art

    o  binary-art

    o  call-flow

    o  hex-dump

    o  svg

    The RFC Series Editor will maintain a complete list of the preferred
    values on the RFC Editor web site, and that list is expected to be
    updated over time.  Thus, a consumer of v3 XML should not cause a
    failure when it encounters an unexpected type or no type is
    specified.  The table will also indicate which type of art can appear
    in plain-text output (for example, type="svg" cannot).



Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


------------------------------

Message: 5
Date: Thu, 23 Jul 2020 06:15:11 +0200
From: Carsten Bormann <cabo at tzi.org>
To: John R Levine <johnl at taugh.com>
Cc: Martin Thomson <mt at lowentropy.net>, rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <4A99E8F7-4D7F-43C4-B66E-0BB27A16387A at tzi.org>
Content-Type: text/plain;       charset=utf-8

On 2020-07-23, at 05:40, John R Levine <johnl at taugh.com> wrote:
>
>   o  svg

In an authoring system such as kramdown-rfc, you get to use source-code (e.g., some form of UML) to generate artwork (right now limited to our SVG subset, or plaintext (?ASCII?) art).

The existing vocabulary cannot represent this.
But that is maybe mostly OK, because at the author-publisher interface, the source code (i.e., editable form) is no longer needed.
Until it is.

Gr??e, Carsten



------------------------------

Message: 6
Date: 23 Jul 2020 00:22:31 -0400
From: "John R Levine" <johnl at taugh.com>
To: "Carsten Bormann" <cabo at tzi.org>
Cc: "Martin Thomson" <mt at lowentropy.net>, rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
Message-ID: <5858459-521b-fa9f-aeff-798fccd9320 at taugh.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On Thu, 23 Jul 2020, Carsten Bormann wrote:
> On 2020-07-23, at 05:40, John R Levine <johnl at taugh.com> wrote:
>>
>>   o  svg
>
> In an authoring system such as kramdown-rfc, you get to use source-code (e.g., some form of UML) to generate artwork (right now limited to our SVG subset, or plaintext (?ASCII?) art).
>
> The existing vocabulary cannot represent this.
> But that is maybe mostly OK, because at the author-publisher interface, the source code (i.e., editable form) is no longer needed.
> Until it is.

This list of artwork types isn't cast in stone.  If we need new ones, we
can add them.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

------------------------------

Subject: Digest Footer

_______________________________________________
rfc-interest mailing list
rfc-interest at rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest


------------------------------

End of rfc-interest Digest, Vol 189, Issue 14
*********************************************
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200723/e4d78ecc/attachment.html>


More information about the rfc-interest mailing list