Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-16.txt

From: "Takeshi Takahashi" <[email-masked]>
Date: Sat, 12 Mar 2016 07:55:35 +0900

Hi Roman,

Let me add one more comment.
The schema seems to be fine, but the examples described in the draft need to
be corrected.

The three examples mentioned in Section 7 have <Email> inside <Contact>.
The <Email> elements cannot have string value, according to the Email class
defined in Section 3.9.3, which says we need to use <EmailTo> to describe
the string.

Take

From: mile [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Saturday, February 13, 2016 1:49 AM
To: Roman D. Danyliw <[email-masked]>
Cc: [email-masked]
Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-16.txt

Hi Roman,
A few quick comments after reviewing the most recent diff:

In 2.17:

formatid might need a bit more details. Can you provide some examples?

In 3.9.4:

When one would use "direct" or when "mobile"? Is "direct" referring to a
landline number or something else?

In 3.21:

In EmailHeaderField description: I don't know what is "SMTP header field". I
think you should revert the change to make it "email header field" again.

Also, it should be "zero or more", not "zero or one".

In 3.25.1:

FileType - this is just media type name, right?

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 14 Mar 2016 12:48:29 +0000

Hello Take!

Thank you for the feedback.  I'll make the change.

Roman

> -----Original Message-----
> From: Takeshi Takahashi [mailto:[email-masked]]
> Sent: Friday, March 11, 2016 5:56 PM
> To: 'Alexey Melnikov' <[email-masked]>; Roman D. Danyliw
> <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-16.txt
> 
> Hi Roman,
> 
> The schema seems to be fine, but the examples described in the draft need
> to be corrected.
>

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 17 Mar 2016 19:12:56 +0000

Hi Alexey!

Thanks for the feedback.

> From: Alexey Melnikov [mailto:[email-masked]]
>
> In 2.17:
> 

This @formatid is a holdover from the original RFC5070.  It is an opaque identifier that an implementer could use to provide guidance on how to parse this extension.

I'm struggling to come up with a good use case, but it would work as follows:

<Extension name="custom field1" dtype="string" meaning="explanation1" formatid="string-type1">
<Extension name="custom field2" dtype="string" meaning="explanation2" formatid="string-type2">

The parser would know to process "custom field1" as a "string-type1" and "custom field 2" as a "string-type2".

Why the format information couldn't be inferred from @name assuming they are uniquely assigned; or an enumerated value set with @ext-dtype="string-type1 or string-type2" isn't clear.  

Remove?

> landline number or something else?

It is referring to a landline/wireline phone.  I can see the confusion so this enumerated value has been renamed to "wired" in -17.
 
> think you should revert the change to make it "email header field" again.

Good point.  Corrected in -17.

> Also, it should be "zero or more", not "zero or one".

Corrected in -17.

> FileType - this is just media type name, right?

Yes.  More specifically the "Template" column of http://www.iana.org/assignments/media-types/media-types.xhtml.

Roman

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 17 Mar 2016 20:12:53 +0000

Hi Roman,

> Why the format information couldn't be inferred from @name assuming they are uniquely assigned; or an enumerated value set with @ext-dtype="string-type1 or string-type2" isn't clear.  

I think either remove or add text (at least examples) to make this implementable from the document.

Best Regards,
Alexey