Hi WG,
Sorry for my late review. This document is quite long. But I think the
overall write-up is clear enough. Please see my comments inline:
Section 6.1., paragraph 3:
>Hence, the event field of ALTO update message can include two sub-
>fields (media-type and data-id), where the two sub-fields are
>separated by a comma:
COMMENT:
As the SSE message can support unicode, indicating that the comma is
(',', U+002C) may be better. This is also consistent with the
character encoding used in other ALTO documents (e.g., Section 10.1
of RFC7285).
Section 6.1., paragraph 5:
>To allow non-ambiguous decoding of the two sub-fields, the media-type
>name used by ALTO SSE MUST NOT contain a comma (character code 0x2c),
>and the string before the comma is the media-type name. [To RFC
>editor: please check this conforms to Section 4.2 of [RFC6838] and
>confirms to IANA.]
COMMENT:
According to the ABNF of Section 4.2 of [RFC6838], the media-type
name can never include a comma. So the "MUST NOT" requirement
can be removed. Instead, we can emphasize there is no ambiguity,
if necessary.
Section 6.2., paragraph 2:
>The `data-id` sub-field identifies the ALTO data to which a data
>update message applies. For a resource containing only a single JSON
>object, the substream-id assigned by the client when requesting the
>SSE service is enough to identify the data. In this document,
>substream-ids MUST follow the rules for ALTO ResourceIds
>(Section 10.2 of [RFC7285]). Substream-ids MUST be unique within an
>update stream, but need not be globally unique. For a resource using
>multipart/related, the `data-id` sub-field must include the
>substream-id, `.` and the unique Content-ID.
COMMENT:
"must" should be capitalized: the `data-id` sub-field must xxx ->
MUST The description "must include substream-id, `.` and the unique
Content-ID" is not clear for me. It seems that this document does
not just require the `data-id` to include these three components,
but be exactly the concatenation of them in order.
The latest revision introduces more generic `data-id` to support multipart
messages. But I do not see an example to show how to use it. We know path
vector is a potential example. Maybe authors do not want to make this
document coupled with path vector.
Cheers,
Jensen
On Fri, Dec 13, 2019 at 10:19 AM Vijay Gurbani
wrote:
> Jensen: Excellent. Thank you!
>
> On Fri, Dec 13, 2019 at 9:04 AM Jensen Zhang
> wrote:
>
>> Hi Vijay and WG,
>>
>> I am reviewing the latest revision of SSE. I will post my review by
>> tonight.
>>
>> Thanks,
>> Jensen
>>
>>
>> On Fri, Dec 13, 2019 at 10:01 AM Vijay Gurbani
>> wrote:
>>
>>> Folks: The WGLC ended for update-sse on Dec 8 [1]. However, we have had
>>> absolutely no discussion on the mailing list about this draft after it was
>>> posted for WGLC.
>>>
>>> I am shepherding this draft, and as such, I will need at least one, and
>>> perhaps two, members from the WG who are not associated with the draft to
>>> perform an indepth review of this draft. I will review it as well as part
>>> of shepherding.
>>>
>>> Please send me an email indicating that you will like to review this
>>> draft, and please let me know when to expect the review by.
>>>
>>> Thank you.
>>>
>>> [1]
>>> https://mailarchive.ietf.org/arch/msg/alto/hHM_bC1CfwygcxTTm96zBbj7gmo
>>> ___
>>> alto mailing list
>>> alto@ietf.org
>>> https://www.ietf.org/mailman/listinfo/alto
>>>
>>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
