icalendar.prop.uri module

URI values from RFC 5545.

class icalendar.prop.uri.vUri(value: str, encoding: str = 'utf-8', /, params: dict[str, Any] | None = None)

Bases: str

URI

Value Name:

URI

Purpose:

This value type is used to identify values that contain a uniform resource identifier (URI) type of reference to the property value.

Format Definition:

This value type is defined by the following notation:

uri = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

Description:

This value type might be used to reference binary information, for values that are large, or otherwise undesirable to include directly in the iCalendar object.

Property values with this value type MUST follow the generic URI syntax defined in [RFC3986].

When a property parameter value is a URI value type, the URI MUST be specified as a quoted-string value.

Examples

The following is a URI for a network file:

http://example.com/my-report.txt

>>> from icalendar.prop import vUri
>>> uri = vUri.from_ical('http://example.com/my-report.txt')
>>> uri
vUri('http://example.com/my-report.txt')
>>> uri.uri
'http://example.com/my-report.txt'

property FMTTYPE: str | None

FMTTYPE specfies the content type of a referenced object.

Conformance:

RFC 5545 specifies the FMTTYPE. RFC 9253 adds FMTTYPE to LINK properties. In a LINK, FMTTYPE maps to the "type" attribute defined in Section 3.4.1 of RFC 8288. See RFC 6838.

Description:

This parameter can be specified on properties that are used to reference an object. The parameter specifies the media type RFC 4288 of the referenced object. For example, on the "ATTACH" property, an FTP type URI value does not, by itself, necessarily convey the type of content associated with the resource. The parameter value MUST be the text for either an IANA-registered media type or a non-standard media type.

Example

A Microsoft Word document:

ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/
 agenda.doc

A website:

LINK;FMTTYPE=text/html;LINKREL=SOURCE;LABEL=Venue;VALUE=URI:
 https://example.com/venue

property GAP: timedelta | None

Purpose:

GAP specifies the length of the gap, positive or negative, between two components with a temporal relationship.

Format Definition:

Same as the DURATION value type defined in RFC 5545, Section 3.3.6.

Description:

This parameter MAY be specified on the RELATED-TO property and defines the duration of time between the predecessor and successor in an interval. When positive, it defines the lag time between a task and its logical successor. When negative, it defines the lead time.

Examples

An example of lag time might be if Task-A is "paint the room" and Task-B is "lay the carpets". Then, Task-A may be related to Task-B with RELTYPE=FINISHTOSTART with a gap of 1 day -- long enough for the paint to dry.

====================
|  paint the room  |--+
====================  |
                      |(lag of one day)
                      |
                      |  ===================
                      +->| lay the carpet  |
                         ===================

For an example of lead time, in constructing a two-story building, the electrical work must be done before painting. However, the painter can move in to the first floor as the electricians move upstairs.

=====================
|  electrical work  |--+
=====================  |
         +-------------+
         |(lead of estimated time)
         |  ==================
         +->|    painting    |
            ==================

property LABEL: str | None

LABEL provides a human-readable label.

Conformance:

This property parameter is specified in RFC 7986, iCalendar Property Extensions.

RFC 9253 makes use of this for the LINK property. This parameter maps to the "title" attribute defined in Section 3.4.1 of RFC 8288. LABEL is used to label the destination of a link such that it can be used as a human-readable identifier (e.g., a menu entry) in the language indicated by the LANGUAGE (if present). The LABEL MUST NOT appear more than once in a given link; occurrences after the first MUST be ignored by parsers.

Description:

This property parameter MAY be specified on the "CONFERENCE" property. It is anticipated that other extensions to iCalendar will reuse this property parameter on new properties that they define. As a result, clients MUST expect to find this property parameter present on many different properties. It provides a human-readable label that can be presented to calendar users to allow them to discriminate between properties that might be similar or provide additional information for properties that are not self-describing. The "LANGUAGE" property parameter can be used to specify the language of the text in the parameter value (as per Section 3.2.10 of RFC 5545).

Examples

This is a label of a chat.

CONFERENCE;VALUE=URI;FEATURE=VIDEO;
    LABEL="Web video chat, access code=76543";
    :https://video-chat.example.com/;group-id=1234

property LANGUAGE: str | None

Specify the language for text values in a property or property parameter.

Description:

This parameter identifies the language of the text in the property value and of all property parameter values of the property. The value of the "LANGUAGE" property parameter is that defined in RFC 5646.

For transport in a MIME entity, the Content-Language header field can be used to set the default language for the entire body part. Otherwise, no default language is assumed.

property LINKREL: str | None

Purpose:

LINKREL specifies the relationship of data referenced by a LINK property.

Conformance:

LINKREL is specified in RFC 9253. This parameter maps to the link relation type defined in Section 2.1 of RFC 8288. It is always quoted.

Description:

This parameter MUST be specified on all LINK properties and define the type of reference. This allows programs consuming this data to automatically scan for references they support. There is no default relation type. Any link relation in the link registry established by RFC 8288, or new link relations, may be used. It is expected that link relation types seeing significant usage in calendaring will have the calendaring usage described in an RFC.

In the simplest case, a link relation type identifies the semantics of a link. For example, a link with the relation type "copyright" indicates that the current link context has a copyright resource at the link target.

Link relation types can also be used to indicate that the target resource has particular attributes, or exhibits particular behaviours; for example, a "service" link implies that the link target can be used as part of a defined protocol (in this case, a service description).

Registration:

There are two kinds of relation types: registered and extension. These relation types are registered in RFC 8288.

See also

Registered Link Relation Types.

Examples

This identifies the latest version of the event information.

LINKREL=latest-version

property RELTYPE: RELTYPE

Specify the type of hierarchical relationship associated with a component.

Conformance:

RFC 5545 introduces the RELTYPE property parameter. RFC 9253 adds new values.

Description:

This parameter can be specified on a property that references another related calendar. The parameter specifies the hierarchical relationship type of the calendar component referenced by the property. The parameter value can be PARENT, to indicate that the referenced calendar component is a superior of calendar component; CHILD to indicate that the referenced calendar component is a subordinate of the calendar component; or SIBLING to indicate that the referenced calendar component is a peer of the calendar component. If this parameter is not specified on an allowable property, the default relationship type is PARENT. Applications MUST treat x-name and iana-token values they don't recognize the same way as they would the PARENT value.

property VALUE: str

The VALUE parameter or the default.

Purpose:

VALUE explicitly specify the value type format for a property value.

Description:

This parameter specifies the value type and format of the property value. The property values MUST be of a single value type. For example, a "RDATE" property cannot have a combination of DATE-TIME and TIME value types.

If the property's value is the default value type, then this parameter need not be specified. However, if the property's default value type is overridden by some other allowable value type, then this parameter MUST be specified.

Applications MUST preserve the value data for x-name and iana-token values that they don't recognize without attempting to interpret or parse the value data.

Returns:

The VALUE parameter or the default.

Examples

The VALUE defaults to the name of the property. Note that it is case-insensitive but always uppercase.

>>> from icalendar import vBoolean
>>> b = vBoolean(True)
>>> b.VALUE
'BOOLEAN'

Setting the VALUE parameter of a typed property usually does not make sense. For convenience, using this property, the value will be converted to an uppercase string. If you have some custom property, you might use it like this:

>>> from icalendar import vUnknown, Event
>>> v = vUnknown("Some property text.")
>>> v.VALUE = "x-type"  # lower case
>>> v.VALUE
'X-TYPE'
>>> event = Event()
>>> event.add("x-prop", v)
>>> print(event.to_ical())
BEGIN:VEVENT
X-PROP;VALUE=X-TYPE:Some property text.
END:VEVENT

default_value: ClassVar[str] = 'URI'

classmethod examples()

Examples of vUri.

Return type:

list[None]

classmethod from_ical(ical)

classmethod from_jcal(jcal_property)

Parse jCal from RFC 7265.

Parameters:

jcal_property (list) -- The jCal property to parse.

Raises:

JCalParsingError -- If the provided jCal is invalid.

Return type:

None

property ical_value: str

The URI.

params: Parameters

to_ical()

to_jcal(name)

The jCal representation of this property according to RFC 7265.

Return type:

list

property uri: str

The URI.