OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] Identifier, Sender and References appear to clashin V1.1 (Also, what about whitespace?)

Bob -

Your latest critique seems to assume a requirement nobody's ever 
raised: to parse a <references> value unambiguously into its 
components.  At present the <references> value is meant to provide a 
globally-unique identifier for a particular instance message, nothing 
more.  Parse-ability isn't required for that.  I wouldn't object to a 
specific proposal that would add that functionality, if folks agree 
it would be a useful improvement, but I wonder whether the TC would 
see that as a priority right now.

As for the whitespace question... I think the definition states 
pretty unambiguously how the <references> value should be formed, and 
it doesn't provide for whitespace, front, back or middle.  If you see 
whitespace in the example, it's a typographic artifact.  And if folks 
add content that's not specified in the definition, they depart from 
the spec at their own risk.  As with the nulls question, if someone 
were to propose some advisory language to underscore that point, I 
imagine the TC might consider adding it.

And as for your latest grumble... if you're prepared to put together 
an ABNF spec and offer it to the committee for consideration, I 
imagine we'd all be interested in seeing it.

- Art

At 1:01 PM -0500 1/31/05, Bob Wyman wrote:
>It appears that alert:identifier and alert:sender in both CAP V1.0 and the
>draft V1.1 are underspecified.
>alert:identifier is defined in part as: "MUST NOT include spaces or
>restricted characters (< and &)"
>alert:sender is similarly defined.
>alert:references is defined in part as: "The extended message identifier(s)
>(in the form identifier/ sender) of an earlier message or messages
>referenced by this one."
>The problem here is that it appears that "/" is a valid character for use in
>both alert:identifier and alert:sender, however, "/" has semantic meaning
>when included in alert:references. Given this conflict, it would be most
>sensible to include "/" in the list of restricted characters that cannot be
>used in either alert:identifier or alert:sender. Without such a restriction,
>it is not possible to parse alert:references to pick out the identifier and
>sender portions. This will make it exceptionally difficult for some systems
>to identify which message is being updated, cancelled, etc.
>If identifier is "message/1" and sender is "tom/bombadil@foo.bar" the
>extended message identifier would be:
>	message/1/tom/bombadil@foo.bar
>It is not possible to determine which part of that extended identifier is
>the identifier and which part is the sender...
>One more question: In the text definition of the extended message identifier
>of alert:references, there is a space following the "/" between "identifier"
>and "sender". Is this space required or otherwise meaningful? Is it
>permitted? This also raises a question concerning whitespace in
>alert:identifier and alert:sender. Is leading, trailing or embedded
>whitespace permitted in these elements? If so, is leading or trailing
>whitespace significant? Note: A "normal" Internet specification would
>include ABNF specifications for these bits and thus eliminate questions such
>as these... Grumble...
>		bob wyman
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]